[rabbitmq-discuss] Broken Pipe in RabbitMQ ConnectionFactory.newConnection()

Mon Sep 9 07:44:32 BST 2013

Michael,
Matthias,

Actually I misclicked and sent the code without some comments (or other
code) that I should have added.

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()) :

if (delivery == null) {
if (System.currentTimeMillis() - start < DEFAULT_TIMEOUT) {
Utils.sleep(200);
continue;
} else {
throw new IOException("Message delivery timed out on " + queueName + "/" +
replyQueueName);
}
}

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.

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.

Thanks!

Regards,
John

On Mon, Sep 9, 2013 at 4:07 AM, Matthias Radestock <matthias at rabbitmq.com>wrote:

> On 08/09/13 23:04, Michael Klishin wrote:
>
>> I can imagine there are potential issues in connection shutdown code
>> in some clients
>>
>
> But there shouldn't be. If so, there's a bug that I'd rather see fixed. I
> don't think there is though...
>
> The OP's problem has all the hallmarks of the client, server, or network
> being overloaded. The "{handshake_timeout,frame_**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.
>
>
>  Consider using a long-lived connection
>>
>
> 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?!
>
> Oh, and another thing...
>
> 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.
>
> Regards,
>
> Matthias.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130909/9a7c0361/attachment.htm>