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"? 2) For the "non-sticky consumer" case: I like Gordon's suggestion of allowing delivery of a sub-sequence of the pending message group to a particular consumer, and using the capacity to set the blocking granularity. I'll update the qip to include this. 3) for the "sticky consumer" case it sounds like there are a couple of variations: a) all messages in a group that are present on the queue will be delivered to a single, arbitrarily selected consumer (best effort w.r.t. client lifespan, no state mapping the group-id to consumer preserved once all messages from the group have been consumed). b) all messages in a group are delivered to a single, arbitrarily selected consumer for the duration of the message group (ditto client lifespan, state mapping with some degree of persistence (?), End-of-Group message marking or sequencing (?) c) other "non-sticky" constraints we need to consider? thanks, -K ----- Original Message ----- > On 06/28/2011 11:39 AM, Gordon Sim wrote: > > So I think the requirements are: > > > > (1) message group must always be processed in order > > > > (2) all messages in a group are processed by the same consumer > > > > (3) the consumer will only complete processing having received the > > 'final' message in the group > > > > Where (3) implies (2) and (2) implies (1). > > Actually on further consideration, I think I need to qualify this last > sentence a little. > > The broker doesn't know what the 'final' message is. However it > requires > some state to track stickiness of group to consumer. In use case (3) I > actually think the assumption on stickiness is the same as for my > preferred implementation of (1). I.e. the association between group > and > consumer only lasts for as long as there are outstanding unaccepted > messages. > > In that sense (3) can be met along with (1). There is of course a > sense > where it may still be true that (3) implies that all the messages in a > group are processed by the same consumer. However that is really based > on the external consideration of whether there will be any further use > of the same group id. > > So I do think that the key distinction is in the scope of the > association between group and consumer. It is either scoped to the > life > of the consumer (satisfying requirement 2) or it is scoped to the > existence of outstanding, unaccepted messages in the group (satisfying > requirements 1 and 3). > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
