launchpad-dev team mailing list archive

[Muharem Hrnjadovic <muharem@xxxxxxxxxx>]

Julian Edwards wrote:
> On Thursday 08 October 2009 22:21:20 Aaron Bentley wrote:
>> I don't think so.  It's no coincidence that Muharem presented a Job system
>> as a use case at the Epic.  Polling will never be as responsive or efficient
>> as messaging.
> 
> I disagree with the word "never".
> 
> I am a huge fan of messaging systems and I have a lot of experience
> with them and also with polling-based solutions.
> 
> Consider the situation where you have several updates causing diff
> requests on the same branch.  You're only interested in the last
> change; with a message for each diff request, calculating the diffs
> in-between is a waste as you will throw them away with subsequent diff
> processing.  If you were to periodically poll, you would see only the
> most recent change and work with that.
> 
> This is a slightly contrived example but you get my drift.

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.

> 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>

Best regards

-- 
Muharem Hrnjadovic <muharem@xxxxxxxxxx>
Public key id   : B2BBFCFC
Key fingerprint : A5A3 CC67 2B87 D641 103F  5602 219F 6B60 B2BB FCFC

Attachment: signature.asc
Description: OpenPGP digital signature