[rabbitmq-discuss] Java Client Using DefaultConsumer vs QueueingConsumer

[Steve Powell]

No it won’t. The normal ordering guarantees are observed.  The thread dispatching algorithm ensures that consumers on the same channel are called serially.

Each call might run on a different thread (or the same thread — the calls might be batched if many messages arrive at once), but, on a particular channel, there is at most one thread working on a consumer callback (like handleDelivery()) at any time.

I thought this was clearly spelt out in the Java Client Doc, but I can only find this:
Callbacks to Consumers are dispatched on a thread separate from the thread managed by the Connection. This means that Consumers can safely call blocking methods on the Connection or Channel, such asqueueDeclare, txCommit, basicCancel or basicPublish.

Each Channel has its own dispatch thread. For the most common use case of one Consumer per Channel, this means Consumers do not hold up other Consumers. If you have multiple Consumers per Channel be aware that a long-running Consumer may hold up dispatch of callbacks to other Consumers on that Channel.

which occurs (buried) in the Channel Thread Safety section. Maybe this should be improved (and a note put in the Consumer Thread Pool section).

Steve Powell  [Cell: +44-7815-838-558]
    Good design […] is as little design as possible.    Dieter Rams

On 3 Apr 2014, at 16:04, Michael Klishin <mklishin at gopivotal.com> wrote:

>> I have also tested it several times and saw that the order is saved. 
>> Just to make sure - since different threads call handle delivery 
>> - will it mess my order?
> 
> By default the pool has 5 threads, so yes. You can provide your own
> executor on ConnectionFactory, e.g. to use a single threaded executor.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140404/d54880ac/attachment.html>