On 06/27/2011 07:54 PM, Robert Godfrey wrote:
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.
Absolutely. I just think that both cases are valuable and a lot of the
implementation is common between them.
With ordering, are you suggesting a strict order based on enqueue time into
the queue, or upon a provided sequence number?
It would be based on enqueue order, i.e. strict FIFO for a given group.
If a message gets
re-enqueued does it retain its original order with respect to the rest of
the group?
By re-enqueued you mean becoming available for redelivery after being
released explicitly or implicitly? If so then yes, I believe it must
keep its original order.
That does of course mean that clients can't accept out of order and
can't arbitrarily release messages. For most applications however I
believe you can still keep the strict ordering even allowing for
'requeuing' due to rollback or connection failure.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
