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.
--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
