I think that topic subscription is, anyway, a special case. More particularly if there is an *exclusive* (in AMQP-speak) consumer on a queue, if it recovers, rollsback or closes then we have a guarantee (since it's exclusive) that there will be no other concurrent access to the queue... further we know that there will be no other unacknowledged messages on the queue other than those from the consumer which is recovering/rolling-back/closing... which makes everything much easier to reason about.
On 08/03/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
Martin Ritchie wrote: > Which would mean that the ordering 4,5,3 may be within the bounds of > JMS. However, if you had sent 5000 messages message 3 would arrive > after those 5000 as this is the default prefetch count in qpid. This > isn't ideal so the current head of qpid now flushes all the messages > from the client and requests new messages. Those messages that have > been flushed return to the front of the queue. However when priority > queues and message expiration are implemented the ordering will > reflect those values. > The behaviour was reported against rev. 512501, it looked to me like 510897 was the revision at which you introduced the ability to requeue at the head. Is that right? Were there subsequent fixes needed as well and if so what revs? Or perhaps more simply, is it worth trying again against the current head?
