On Tue, Oct 5, 2010 at 3:17 PM, Stuart Bishop <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
