qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Proposed QIP: Support for Message Grouping in the broker.
Date Tue, 28 Jun 2011 10:50:55 GMT
On 06/27/2011 12:41 PM, Gordon Sim wrote:
> On 06/27/2011 05:25 PM, Robert Godfrey wrote:
>> So, in general this looks good, and is something we could support in the
>> Java Broker... My one comment would be that I think the more standard
>> behaviour for a "Group" is to ensure all messages in the same group are
>> delivered (in order) to the same consumer, with the notion of blocking
>> delivery of the nth + 1 element of the group until the nth element is
>> acknowledged seeming more like an alternate behaviour.
>
> I don't see a lot of value in blocking delivery of the nth +1 element until the
> nth element is acknowledged. I think the important thing is to deliver the
> messages within a group in order in spite of having competing consumers. You can
> do that simply by ensuring that the nth + 1 message here goes to the same
> consumer as the nth message.
>
> I agree that a common approach is for a group to be 'sticky' to a given consumer.
>
> However I can also see value in a scheme where that stickiness ends not when the
> consumer is closed, but when there are no outstanding in-doubt messages for the
> group. In the case where the requirement is simply in-order processing of
> messages in a group this might allow for more adaptive load balancing across
> parallel consumers.


The sticky approach seems more intuitively obvious to me, but that makes me 
wonder how the non-sticky alternative ever came up in the first place if it's 
not a requirement for somebody. E.g. weblogic 
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/uoo.html phrases 
this in a non-sticky way. Of course the sticky approach is a legitimate 
implementation since "will be sent to any consumer" is not violated if you 
happen to keep choosing the same consumer, but I wonder if the load balancing is 
something that some users would want.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message