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 14:31:22 GMT
On 06/28/2011 03:06 PM, Gordon Sim wrote:
> On 06/28/2011 02:34 PM, Ken Giusti wrote:
>> This is great feedback - thanks to all.
>> I think the term "Message Groups" may not be the best term to use as
>> the name for this feature, as proposed in the qip. I agree that the
>> term "Message Group" has historically implied a sticky consumer - at
>> least that's what Google leads me to believe.
>> The qip wasn't clear regarding the priority of "sticky consumer"
>> support - as Gordon correctly points out, this qip should lay the
>> foundation for supporting both behaviours, as (I believe) there is
>> value in both approaches.
>> So: 1) I'd like to rename the QIP - is there a better term to use for
>> the "non-sticky" case than "Message Groups"?
> I actually quite like 'Message Groups' as a term, I just think there are
> different ways of treating a group.
> I think that rather than 'sticky' and 'non-sticky' we really just have two modes
> of stickiness, i.e. two scopes for the association between group and consumer.
> In the first mode the group is tied to a consumer only while that consumer has
> outstanding, unaccepted messages.
> This is sufficient to guarantee strict fifo processing in a group.
> It also meets Marnie's requirement of having the 'group as a whole' processed by
> the client without having to have any explicit end-of-group signal that the
> broker needs to recognise. The client implicitly signals the end-of-group when
> it acknowledges the messages in the group.
> The second mode extends the scope of the association. The group here is tied to
> a consumer for the life of that consumer. This meets Rob's further requirement
> of allowing any state required and/or built-up during processing of the group to
> be contained within the single consumer.

It seems to me that the first mode contains the second: the client can simply 
delay acknowledgement of at least one message until it is happy that the entire 
group is processed (which could be the entire life of the consumer, or some 
shorter span at the clients discretion.)

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

View raw message