[rabbitmq-discuss] Confirmation listeners and closing a channel
simone.busoli at gmail.com
Mon Jan 23 20:50:21 GMT 2012
I'm not confident with the Java API but although ideally it would make
sense to be able to configure whether the channel waits for confirms before
closing, it is sensible for it to wait, as it appears it is doing here.
Also mandatory doesn't have anything to do with this, check the protocol
specification for that; you can see that even without the mandatory flag
you'll experience the same behavior.
What seems to be happening here is that when you call close your listeners
are removed but the channel, since in confirm mode, will still wait for all
confirms to arrive. It probably has its own listeners inside and until all
messages are either acked or nacked it will wait.
Finally, I noticed that version 2.7.1 of the broker (at least), publication
rate being equal will send confirms in batches when messages are persistent
and one by one when messages are transient, if that's on any help to you.
On Mon, Jan 23, 2012 at 21:39, Adam Rabung <adamrabung at gmail.com> wrote:
> I am trying to understand the effect ConfirmationListeners have on channel
> closing. It looks like if messages are published with "mandatory=true",
> the corresponding Channel.close will block until all notifications have
> been received (unsure of any timeout, I've seen it block for over a
> minute). I understand "mandatory" to mean "return the message to all
> Return/Confirm listeners". Is this blocking behavior also part of
> mandatory behavior, or should close() happen immediately?
> Something else interesting happens when you close a channel with pending
> callbacks: listeners are immediately removed. The consequence is you block
> until all confirmations/returns have happened, but your listeners don't
> receive them.
> Here's some example code:
> If you call this with
> RabbitTest.publish(0, exchange, routingKey, msg, brokerAddress);
> prints "0 callbacks, waited 0ms before close, close took 5959"
> RabbitTest.publish(5000, exchange, routingKey, msg, brokerAddress);
> prints "427 callbacks, waited 5000ms before close, close took 833"
> Note how both take roughly 5800ms. On the first call, we don't pause
> before calling close, and receive 0 callbacks. However, the second one,
> which waits 5000ms before trying to call close, gets most of the callbacks.
> A longer pause before close results in all callbacks being handled.
> To reproduce this, I use a roughly 200 character string as my message.
> It's also important that the message be published as "persistent" - I
> think transient messages are too fast to reveal this :)
> Should callbacks block close? If so, should listeners continue to receive
> callbacks as close happens?
> Thank you,
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss