On 27 June 2011 17:41, Gordon Sim <[email protected]> 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. > > Sure, but the two schemes are not interchangeable... if the reason that the client wants the "sticky" behaviour is that they are going to maintain state at that and only that client for the processing of that group, then the ordering guarantee does not help them (and indeed may be contrary to their expectations). The question is whether people are using grouping for strict ordering, or to ensure a locality for processing messages of the same group.
With ordering, are you suggesting a strict order based on enqueue time into the queue, or upon a provided sequence number? If a message gets re-enqueued does it retain its original order with respect to the rest of the group? -- Rob
