[rabbitmq-discuss] persistent connections on rabbitmq-server when android client losses internet connection

[Tim Watson]

Hi,

On 11 May 2013, at 13:08, Jure Novič wrote:

> I have a question about about connections to server from java client. I'm developing a Android application using rabbitmq-java-client library. I followed the tutorials on the rabbitmq website, so I created a ConnectionFactory with my own ip address (without any timeout or heartbeat), then called newConnection(). Everything works fine, sending and receiving.
> 
> The problem arrises when I turn off network connection on an android device, the connection on rabbitmq-server is still there (for long time). If I want to achieve that the server clear my connection I have to use heartbeat. I also tried to create new ConnectionFactory class and override configureSocket and call socket.setKeepAlive(true). That neither helped. 

If I'm not mistaken, you'll need to enable TCP keep-alive at the OS level to take advantage of that. Check out `man tcp`, at which point you might want to consider 'tcp_retries1' and the RTO settings as well. Better still, get your network admin to look at these, since they'll have a much better idea of the impact any changes might have. 

> 
> My colleague is developing an iOS application, and another one is developing an erlang client. They don't have this problem, if they kill the app or turn of network connection, the connections on rabbitmq-server are cleared immediately (2-4s). They are not using any timeouts or heartbeats.

Perhaps that's true at the application level, but it's entirely possible that at the OS level (on either client or server) they have configured the network stack to detect connection failures in a timely fashion. This could be the case either because they've explicitly tuned the kernel's TCP parameters themselves, or that their chosen OS provides different defaults to yours. If this is not the case, it's also possible that intermediate network kit (such as routers, load balancers, proxies and firewalls) could be responsible for the timely detection of a closed socket.

Cheers,
Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130513/6e92671f/attachment.htm>