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:[email protected]
