[rabbitmq-discuss] Unexpected blocking in channel.basicGet()

Fri May 3 17:19:02 BST 2013

On 3 May 2013, at 16:53, Dave Goldstein wrote:

> So if the call blocks indefinitely without erroring out, what does that suggest 
> 

The usual suspect is a network connectivity problem, either due to an interruption in service, broker failure/crash/restart or intermediate network kit (such as firewalls). A typical TCP/IP stack can take quite a long time to "notice" the peer socket has "disappeared", while the client is sat waiting for a reply.

> and is there any way for me to recover from this beyond detecting and killing the thread?

Unfortunately there aren't any silver bullet solutions to this kind of problem. Detecting an idle worker (based on whatever your definition of "idle" happens to be) and killing it is certinaly the must common approach. Bear in mind that the OS networking stack is already trying to 'detect' the problem, and it's unlikely you'll be able to improve on what it is doing.

It might help if you enable AMQP heartbeats in your client, which would at least detect an unresponsive network connection in a timely fashion. These will do the job of killing the connection and any channels for you, so at least you don't have to home bake a solution based on killing threads. The other thing that might help is to consider turning on TCP keep-alives in your OS networking configuration. These perform a similar function, but at a much lower level, however they come with overheads and caveats that they might affect your application (and/or other network interactions taking place on the machine) in a wide variety of ways.

> BTW, I was running client 3.0.1 and have just moved to 3.0.4 to see if the behavior changes.
>  

This won't have changed between releases, if I've diagnosed it correctly at least.

Cheers,
Tim