<font face="trebuchet ms,sans-serif">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.</font><div>
<font face="trebuchet ms,sans-serif">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.</font></div>
<div><font face="trebuchet ms,sans-serif">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.</font></div>
<div><font face="trebuchet ms,sans-serif">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.</font></div>
<div><font face="'trebuchet ms', sans-serif"><br></font></div><div><font face="'trebuchet ms', sans-serif">Simone</font></div><div><br><div class="gmail_quote">On Mon, Jan 23, 2012 at 21:39, Adam Rabung <span dir="ltr"><<a href="mailto:adamrabung@gmail.com" target="_blank">adamrabung@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<div>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?</div>
<div><br></div><div>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. </div>
<div><br></div><div>Here's some example code:</div><div><a href="https://gist.github.com/1665378" target="_blank">https://gist.github.com/1665378</a></div><div><br></div><div>If you call this with </div><div><div>RabbitTest.publish(0, exchange, routingKey, msg, brokerAddress);</div>
<div>prints "0 callbacks, waited 0ms before close, close took 5959"</div><div><br></div><div>RabbitTest.publish(5000, exchange, routingKey, msg, brokerAddress);</div></div><div>prints "427 callbacks, waited 5000ms before close, close took 833"</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 :)</div>
<div><br></div><div>Should callbacks block close? If so, should listeners continue to receive callbacks as close happens?</div><div><br></div><div>Thank you,</div><div>Adam</div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>