<div dir="ltr">Michael,<div>Matthias,</div><div><br></div><div>Actually I misclicked and sent the code without some comments (or other code) that I should have added.</div><div><br></div><div>For the nextDelivery w/ 100 ms timeout and the expiration, after the delivery = consumer.nextDelivery(100) line I am handling both sleeping a bit in case of no delivery and timing out in case message is presumably expired (in which case BTW a finally clause calls the connection.abort()) :</div>
<div><br></div><div><br></div><div><div><span class="" style="white-space:pre"> </span>if (delivery == null) {</div><div><span class="" style="white-space:pre"> </span>if (System.currentTimeMillis() - start < DEFAULT_TIMEOUT) {</div>
<div><span class="" style="white-space:pre"> </span>Utils.sleep(200);<span class="" style="white-space:pre"> </span><br></div><div><span class="" style="white-space:pre"> </span>continue;</div><div><span class="" style="white-space:pre"> </span>} else {</div>
<div><span class="" style="white-space:pre"> </span>throw new IOException("Message delivery timed out on " + queueName + "/" + replyQueueName);</div><div><span class="" style="white-space:pre"> </span>}<span class="" style="white-space:pre"> </span></div>
<div><span class="" style="white-space:pre"> </span>}<span class="" style="white-space:pre"> </span></div></div><div><br></div><div>I snipped it initially as irrelevant to the issue not to clutter up the code, but now I see how I should have left it in.</div>
<div><br></div><div>In any case I've seen the error in my ways about creating new connections for every request, I will start reusing connections (and maybe queues) and see if that helps.</div><div><br></div><div>Thanks!</div>
<div><br></div><div>Regards,</div><div>John</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 4:07 AM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 08/09/13 23:04, Michael Klishin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can imagine there are potential issues in connection shutdown code<br>
in some clients<br>
</blockquote>
<br></div>
But there shouldn't be. If so, there's a bug that I'd rather see fixed. I don't think there is though...<br>
<br>
The OP's problem has all the hallmarks of the client, server, or network being overloaded. The "{handshake_timeout,frame_<u></u>header}" in the logs indicates that the connection establishment handshake took longer than 10 seconds. The reported connection.close hang is another indication. To the OP: it should not hang indefinitely; it would be good to find out how long it takes to return and what 'rabbitmqctl list_connections' says at the time.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Consider using a long-lived connection<br>
</blockquote>
<br></div>
That's good advise. I also recommend re-using the temporary reply queues; creating one queue per rpc is really inefficient. And finally, get rid of the semi-busy loop in the consuming code. What's the point of calling nextDelivery with a 100ms timeout, when the code simply loops around on timeout?!<br>
<br>
Oh, and another thing...<br>
<br>
The code is setting an expiry on the published message. If that ever gets triggered, then no reply will be sent and the code becomes stuck going round the aforementioned consumer loop forever.<br>
<br>
Regards,<br>
<br>
Matthias.<br>
</blockquote></div><br></div>