launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

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.