[rabbitmq-discuss] Destroying connection after ShutdownSignalException

Abid Varshani abid.varshani at gmail.com
Fri Nov 1 09:25:46 GMT 2013


Thanks Michael.

I will relook at my code to see where is it going wrong.

Thanks
Abid


On Fri, Nov 1, 2013 at 2:26 PM, Michael Klishin <mklishin at gopivotal.com>wrote:

> On 1 Nov 2013, at 12:46, Abid Varshani <abid.varshani at gmail.com> wrote:
>
> > 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.
>
> If you reconnect, RabbitMQ treats every new connection as a separate one.
> It cannot know if it’s coming
> from a client that was connected earlier or not. In fact, as soon as it
> detects a closed connection,
> all unacknowledged messages will be requeued.
>
> Please investigate what changes between reconnections. It can be queue
> names (for server-named queues),
> queues getting deleted (for exclusive or auto-delete queues), bindings not
> being recovered, etc.
>
> Both the client and RabbitMQ do not notice TCP connection loss immediately
> because of how TCP works:
> it tries retransmitting segments first, then gives up after a certain
> period of time. AMQP 0-9-1 has heartbeats
> exactly for this reason: to make it easier for detect unresponsive peers.
>
> So try setting a heartbeat interval to a low value (say, 4-6 seconds) and
> see if it helps.
>
> As far as connection loss for publishers goes, unless the peer gets
> unresponsive in the middle of a write
> (to the socket), you should get a visible IOException the next time you
> publish a message.
> --
> MK
>
> Software Engineer, Pivotal/RabbitMQ
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131101/bfd3a6ec/attachment.htm>


More information about the rabbitmq-discuss mailing list