RabbiMQ recovering connection error

[Georgian Benetatos]

The problem part of the code 

 @Override
 public void run() {
     while (isRunning) {
       QueueingConsumer.Delivery delivery = null;
       try {
          delivery = consumer.nextDelivery();
          LogUtil.hecsLog("xxxxx", delivery.getBody().toString());
          channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);


       } catch (ShutdownSignalException | ConsumerCancelledException | InterruptedException | IOException e) {
         LogUtil.hecsLog("xxxxxxxx", consumer.toString());
         isRunning = false;
 
       }
    }
 }

I see that the connection and the channel recovers ok, but not my Queueing consumer.

11-18 19:24:48.528: W/System.err(8921): DefaultExceptionHandler: Consumer com.rabbitmq.client.QueueingConsumer@42ef62d8 (amq.ctag-DbGsS3nubmIqRea5vxumRA) method handleDelivery for channel AMQChannel(amqp://pro...@86.122.51.121:5672/,1) threw an exception for channel AMQChannel(amqp://pro...@86.122.51.121:5672/,1):

11-18 19:24:48.528: W/System.err(8921): com.rabbitmq.client.ShutdownSignalException: connection error

11-18 19:24:48.528: W/System.err(8921): at com.rabbitmq.client.QueueingConsumer.checkShutdown(QueueingConsumer.java:172)

11-18 19:24:48.528: W/System.err(8921): at com.rabbitmq.client.QueueingConsumer.handleDelivery(QueueingConsumer.java:124)

11-18 19:24:48.528: W/System.err(8921): at com.rabbitmq.client.impl.ConsumerDispatcher$5.run(ConsumerDispatcher.java:144)

11-18 19:24:48.528: W/System.err(8921): at com.rabbitmq.client.impl.ConsumerWorkService$WorkPoolRunnable.run(ConsumerWorkService.java:95)

11-18 19:24:48.528: W/System.err(8921): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)

11-18 19:24:48.528: W/System.err(8921): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)

11-18 19:24:48.528: W/System.err(8921): at java.lang.Thread.run(Thread.java:841)

11-18 19:24:48.528: W/System.err(8921): Caused by: java.net.SocketException: recvfrom failed: ETIMEDOUT (Connection timed out)

11-18 19:24:48.528: W/System.err(8921): at libcore.io.IoBridge.maybeThrowAfterRecvfrom(IoBridge.java:545)

11-18 19:24:48.528: W/System.err(8921): at libcore.io.IoBridge.recvfrom(IoBridge.java:509)

11-18 19:24:48.538: W/System.err(8921): at java.net.PlainSocketImpl.read(PlainSocketImpl.java:489)

11-18 19:24:48.538: W/System.err(8921): at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)

11-18 19:24:48.538: W/System.err(8921): at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:241)

11-18 19:24:48.538: W/System.err(8921): at java.io.InputStream.read(InputStream.java:162)

11-18 19:24:48.538: W/System.err(8921): at java.io.BufferedInputStream.fillbuf(BufferedInputStream.java:142)

11-18 19:24:48.538: W/System.err(8921): at java.io.BufferedInputStream.read(BufferedInputStream.java:227)

11-18 19:24:48.538: W/System.err(8921): at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:157)

11-18 19:24:48.538: W/System.err(8921): at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:95)

11-18 19:24:48.538: W/System.err(8921): at com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:139)

11-18 19:24:48.538: W/System.err(8921): at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:534)

11-18 19:24:48.538: W/System.err(8921): ... 1 more

11-18 19:24:48.538: W/System.err(8921): Caused by: libcore.io.ErrnoException: recvfrom failed: ETIMEDOUT (Connection timed out)

11-18 19:24:48.538: W/System.err(8921): at libcore.io.Posix.recvfromBytes(Native Method)

11-18 19:24:48.538: W/System.err(8921): at libcore.io.Posix.recvfrom(Posix.java:141)

11-18 19:24:48.538: W/System.err(8921): at libcore.io.BlockGuardOs.recvfrom(BlockGuardOs.java:164)

11-18 19:24:48.538: W/System.err(8921): at libcore.io.IoBridge.recvfrom(IoBridge.java:506)

11-18 19:24:48.538: W/System.err(8921): ... 11 more

[Andrius N.]

Hi. Have you found an answer? I got the same problem - connection is recovered, but not (auto-delete) queues.

2014 m. lapkritis 18 d., antradienis 19:30:27 UTC+2, Georgian Benetatos rašė:

The problem part of the code 

 @Override
 public void run() {
     while (isRunning) {
       QueueingConsumer.Delivery delivery = null;
       try {
          delivery = consumer.nextDelivery();
          LogUtil.hecsLog("xxxxx", delivery.getBody().toString());
          channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);


       } catch (ShutdownSignalException | ConsumerCancelledException | InterruptedException | IOException e) {
         LogUtil.hecsLog("xxxxxxxx", consumer.toString());
         isRunning = false;
 
       }
    }
 }

I see that the connection and the channel recovers ok, but not my Queueing consumer.

11-18 19:24:48.528: W/System.err(8921): DefaultExceptionHandler: Consumer com.rabbitmq.client.QueueingConsumer@42ef62d8 (amq.ctag-DbGsS3nubmIqRea5vxumRA) method handleDelivery for channel AMQChannel(amqp://program@86.122.51.121:5672/,1) threw an exception for channel AMQChannel(amqp://program@86.122.51.121:5672/,1):

[Michael Klishin]

QueueingConsumer IS NOT supported by automatic connection recovery. It should not be used in with modern

Java client versions, period. We've eradicated it from all of our tutorials and most of the docs.

Use a different consumer implementation (e.g. subclass DefaultConsumer) if you expect recovery.

--
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.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

QueueingConsumer IS NOT supported by automatic connection recovery. It should not be used in with modern

Java client versions, period. We've eradicated it from all of our tutorials and most of the docs.

Use a different consumer implementation (e.g. subclass DefaultConsumer) if you expect recovery.

[Andrius Norkaitis]

I use QueueingConsumer with no automatic recovery. Till RabbitMQ version 3.6.0 everything worked fine.

When QueueingConsumer exits consumption, channel is recreated and queue (exclusive) is recreated. What happens now is that on queue recreate it finds out that queue still exist, so it's not recreated. After several seconds server deletes queue, so java client is left with connection with no binded queue.

No client code was changed and prio 3.6.0 it was working very well. Was there any changes in 3.6.0 server which may changed this expected behaviour of auto-delete queues and reconnection?

BR,

Andrius

You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/8GmL_78ktXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.

[Michael Klishin]

 On 23 February 2016 at 18:05:55, Andrius Norkaitis (and...@gmail.com) wrote:
> I use QueueingConsumer with no automatic recovery. Till RabbitMQ
> version 3.6.0 everything worked fine.
> When QueueingConsumer exits consumption, channel is recreated
> and queue (exclusive) is recreated. What happens now is that
> on queue recreate it finds out that queue still exist, so it's
> not recreated. After several seconds server deletes queue,
> so java client is left with connection with no binded queue.
>
> No client code was changed and prio 3.6.0 it was working very well.
> Was there any changes in 3.6.0 server which may changed this expected
> behaviour of auto-delete queues and reconnection?

You seem to be using exclusive and auto-delete queues interchangeably?
No, there were no changes around that.

It takes a while to detect connection loss. This is explained in http://rabbitmq.com/heartbeats.html
in a reasonable amount of detail. So your code seem to have a timing dependency.
If you perform connection recovery manually, you can increase initial recovery delay. Otherwise
my suggestion would be to pick a more suitable heartbeat interval (1 second is NOT a good idea but
60 is also too large for you), or stop using QueueingConsumer and use automatic connection
recovery. FWIW I don't recall anybody reporting this issue, with or without automatic recovery enabled.