On Friday 09 October 2009 16:30:50 Muharem Hrnjadovic wrote: > A very interesting example .. usually solved with a counting > queue ingress/egress filter i.e. one that maintains a "lookup > table" that answers the following question: > > How many messages with a given ID do I have in the queue of > interest? > > The "lookup table" counters are incremented/decremented upon > enqueueing/dequeueing the messages. > > A dequeued message is *processed* if the "lookup table" counter for its > ID is zero and discarded otherwise.
This sounds like just a fancy way of polling. Presumably it's anticipating that the queue will never fill more quickly than it can be emptied? Because it will fail otherwise. With real polling that won't happen and you're doing a lot less processing to boot. > > Basically, there is a trade-off between responsiveness and efficient > > processing. > > While I tend to agree, I'd also like to point out that messaging is a > vast area and that there's a (well known) pattern for almost every > situation :) > > <my$0.02> > IMHO polling is not a good approach in 99.9% of all cases unless > you're building a system with (pseudo) real-time properties. > </my$0.02> Pseudo real-time is where my experience lies. :) If there's any chance of benefiting from aggregation of cumulative updates then you're always going to end up doing something that smells like polling one way or another. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
