[rabbitmq-discuss] previous connection is NOT automatically closed if IP different

Sat Nov 2 13:39:41 GMT 2013

Hi MK,

I am aware of the heartbeat setting. However, my application is running on
mobile phone I afraid that if I set the value to lower value like 10s it
will consume more battery power and also cause higher data usage.

Yes, I can receive all messages ultimately. However, I hope that I can get
those messages in real-time and in the order those messages were published.

"Your problem is likely that the unacknowledged messages on the old
connection are not being re-queued until RabbitMQ detects connection
closure."
Is there any way to ensure that the unacknowledged messages on the old
connection are being re-queued immediately and being delivered to other
consumer?

Regards,
Nick

On Sat, Nov 2, 2013 at 4:17 PM, Michael Klishin <mklishin at gopivotal.com>wrote:

> On 2 Nov 2013, at 09:31, Liong Hung Wong <lhwong at gmail.com> wrote:
>
> > I am jusing rabbitmq-java client. is this a bug?
> >
> > What can I do to ensure that I can receive all of the messages
> immediately even in the scenario in which IP is different?
>
> This is how TCP works: it retries retransmission and waits for a certain
> period of time
> before completely closing the connection.
>
> Heartbeat timeout is the feature that undoes this. Set it to a lower value
> (say, 10 seconds)
> in the client:
>
>
> http://hg.rabbitmq.com/rabbitmq-java-client/file/718eae51bf20/src/com/rabbitmq/client/ConnectionFactory.java#l325
>
> You *can* receive all the messages from a different connection. Whether
> the client IP is the same does not matter.
> Your problem is likely that the unacknowledged messages on the old
> connection are not being re-queued until RabbitMQ detects connection
> closure.
>
> Again, see above about heartbeat setting in the client.
>
> MK
>
> Software Engineer, Pivotal/RabbitMQ
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131102/58b23d4b/attachment.htm>