launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Tue, Oct 5, 2010 at 3:17 PM, Stuart Bishop
<stuart.bishop@xxxxxxxxxxxxx> wrote:
> I actually see a combination of all three for 'tasks'. If a task needs
> to be scheduled, you create the task. You also send an event via
> rabbitmq so the handler for that task does not have to poll. You also
> have a small job in garbo that sends events via rabbitmq for 'lost'
> tasks.

Sure, there's no reason that the task system can't build on Rabbit if
appropriate; and for things that have DB records indicating they need
doing (or things we should scan for dropped events) then garbo glue is
sensible as well.

> (of course, if we have a good enough guarantee of delivery we don't
> need to worry about 'lost' tasks.)

Rabbit isn't reliable - specifically by default it doesn't fsync
before acknowledging, and it has no HA story to deal with server
crashes/power failures.

As an example of something which doesn't need reliability, consider a
long poll callback when a branch has a new revision - anyone viewing
any page with that branch on it can get triggered to update. If the
message is dropped, we don't care - the fact a user is on that page is
intrinsically transient anyway.

-Rob