<div dir="ltr">Thanks Michael.<div><br></div><div>I will relook at my code to see where is it going wrong.</div><div><br></div><div>Thanks</div><div>Abid<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 1, 2013 at 2:26 PM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.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 1 Nov 2013, at 12:46, Abid Varshani <<a href="mailto:abid.varshani@gmail.com">abid.varshani@gmail.com</a>> wrote:<br>
<br>
> 8. Android client receives every other message. That gives me a feeling that RabbitMQ is still assuming the earlier client is still connected and sending the messages to it.<br>
<br>
</div>If you reconnect, RabbitMQ treats every new connection as a separate one. It cannot know if it’s coming<br>
from a client that was connected earlier or not. In fact, as soon as it detects a closed connection,<br>
all unacknowledged messages will be requeued.<br>
<br>
Please investigate what changes between reconnections. It can be queue names (for server-named queues),<br>
queues getting deleted (for exclusive or auto-delete queues), bindings not being recovered, etc.<br>
<br>
Both the client and RabbitMQ do not notice TCP connection loss immediately because of how TCP works:<br>
it tries retransmitting segments first, then gives up after a certain period of time. AMQP 0-9-1 has heartbeats<br>
exactly for this reason: to make it easier for detect unresponsive peers.<br>
<br>
So try setting a heartbeat interval to a low value (say, 4-6 seconds) and see if it helps.<br>
<br>
As far as connection loss for publishers goes, unless the peer gets unresponsive in the middle of a write<br>
(to the socket), you should get a visible IOException the next time you publish a message.<br>
--<br>
MK<br>
<br>
Software Engineer, Pivotal/RabbitMQ<br>
<br>
</blockquote></div><br></div></div></div>