Channel waitForConfirmsOrDie(timout) blocking forever

[Alan Quinton]

Hi,

   I am using rabbitmq 3.4.3 and occasionally one of our JVM threads blocks forever even though we have specifically set a timeout:

WARNING: Thread Thread[vert.x-worker-thread-3,5,main] has been blocked for 96248 ms, time limit is 60000 io.vertx.core.VertxException: Thread blocked at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.rabbitmq.utility.BlockingCell.get(BlockingCell.java:50) at com.rabbitmq.utility.BlockingCell.get(BlockingCell.java:65) at com.rabbitmq.utility.BlockingCell.uninterruptibleGet(BlockingCell.java:111) at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:37) at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:349) at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:573) at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:505) at com.rabbitmq.client.impl.ChannelN.waitForConfirmsOrDie(ChannelN.java:224)

In this case, waitForConfirmsOrDie correctly internally throws a TimeoutException after 5 secs, however in the catch block it then proceeds to call close() on the channel which blocks forever. Irrespective of whatever communication issue happening with the RMQ server, why is close() not honoring this timeout? We cannot have threads blocking for so long in our application.

Is there any workaround for this?

Thanks,

Alan

[Michael Klishin]

Recent Java client versions have a per operation timeout internally. Have you considered upgrading the client? The waitForConfirms method group isn't the only way of using publisher confirms either.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Quinton]

Hi,

   Thanks for the reply. Yea I see the latest version has a hardcoded 10sec timeout internally. I guess that's better. We will look at upgrading and investigating new publish confirms methods.

Alan

[Michael Klishin]

Sounds good. Confirm listeners have been around for a while, by the way.

On Fri, Aug 5, 2016 at 2:21 PM, Alan Quinton <aqui...@gmail.com> wrote:

Hi,

   Thanks for the reply. Yea I see the latest version has a hardcoded 10sec timeout internally. I guess that's better. We will look at upgrading and investigating new publish confirms methods.

Alan

On Friday, August 5, 2016 at 1:02:32 PM UTC-7, Michael Klishin wrote:

Recent Java client versions have a per operation timeout internally. Have you considered upgrading the client? The waitForConfirms method group isn't the only way of using publisher confirms either.

On 5 ago 2016, at 12:22, Alan Quinton <aqui...@gmail.com> wrote:

Hi,

   I am using rabbitmq 3.4.3 and occasionally one of our JVM threads blocks forever even though we have specifically set a timeout:

WARNING: Thread Thread[vert.x-worker-thread-3,5,main] has been blocked for 96248 ms, time limit is 60000 io.vertx.core.VertxException: Thread blocked at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at com.rabbitmq.utility.BlockingCell.get(BlockingCell.java:50) at com.rabbitmq.utility.BlockingCell.get(BlockingCell.java:65) at com.rabbitmq.utility.BlockingCell.uninterruptibleGet(BlockingCell.java:111) at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:37) at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:349) at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:573) at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:505) at com.rabbitmq.client.impl.ChannelN.waitForConfirmsOrDie(ChannelN.java:224)

In this case, waitForConfirmsOrDie correctly internally throws a TimeoutException after 5 secs, however in the catch block it then proceeds to call close() on the channel which blocks forever. Irrespective of whatever communication issue happening with the RMQ server, why is close() not honoring this timeout? We cannot have threads blocking for so long in our application.

Is there any workaround for this?

Thanks,

Alan

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ