AutorecoveringConnection and java.net.SocketException: Connection reset

[Scott Nichol]

I am using AutorecoveringConnection (by calling setAutomaticRecoveryEnabled(true) on ConnectionFactory), but after a java.net.SocketException: Connection reset, it never seems to recover.  I see the following snippet in the stack trace in my application's logs repeatedly even though the RabbitMQ server is definitely running and reachable.  When I stop the app and start it again, it connects right away.  This application is consuming messages, not publishing.

Caused by: com.rabbitmq.client.AlreadyClosedException: connection is already closed due to connection error; cause: java.net.SocketException: Connection reset

               at com.rabbitmq.client.impl.AMQConnection.ensureIsOpen(AMQConnection.java:173) ~[amqp-client-3.3.4.jar:na]

               at com.rabbitmq.client.impl.AMQConnection.createChannel(AMQConnection.java:494) ~[amqp-client-3.3.4.jar:na]

               at com.rabbitmq.client.impl.recovery.AutorecoveringConnection.createChannel(AutorecoveringConnection.java:90) ~[amqp-client-3.3.4.jar:na]

Note that my code is calling Connection#createChannel explicitly; that call is not part of the recovery.

So

1. Is my expectation that the autorecovering connection will attempt to reconnect after a SocketException correct?
2. I have left other factory configuration properties at their default values.  Should I be setting any of them to other values to successfully recover from the exception?
3. Is my next best step in troubleshooting to register listeners on the connection so I can log events to get some insight into what is happening, or is there something else that would be more useful?

TIA

[Michael Klishin]

1. Yes but please use 3.4.1 release of the client.
2. Topology recovery is on by default.
3. Use wireshark to see what's going on the wire. "Connection reset" certainly suggests it may be something other than the client.

3.3.0 or so did not recover from some exceptions but 3.4.1 will re-try on anything.

MK

[Siddhartha Singh]

I am getting the same issue with 3.6.3 client as well.

[Tomoyo]

MK:

   I am getting the same issue with 3.6.1 client as well. 

com.rabbitmq.client.ShutdownSignalException: connection error

at com.rabbitmq.client.QueueingConsumer.handle(QueueingConsumer.java:203) ~[amqp-client-3.6.1.jar:na]

at com.rabbitmq.client.QueueingConsumer.nextDelivery(QueueingConsumer.java:220) ~[amqp-client-3.6.1.jar:na]

at cn.wonhigh.o2o.rabbitmq.common.lqueue.processer.LqueueProcesserManager.processRpc(LqueueProcesserManager.java:92) ~[rabbitmq-common-0.1.0-20160923.084758-40.jar:0.1.0-SNAPSHOT]

at cn.wonhigh.o2o.rabbitmq.common.lqueue.LqueueWorker.startLinstener(LqueueWorker.java:161) [rabbitmq-common-0.1.0-20160923.084758-40.jar:0.1.0-SNAPSHOT]

at cn.wonhigh.o2o.rabbitmq.common.lqueue.LqueueWorker.run(LqueueWorker.java:128) [rabbitmq-common-0.1.0-20160923.084758-40.jar:0.1.0-SNAPSHOT]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_65]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_65]

at java.lang.Thread.run(Thread.java:745) [na:1.7.0_65]

Caused by: java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:196) ~[na:1.7.0_65]

at java.net.SocketInputStream.read(SocketInputStream.java:122) ~[na:1.7.0_65]

at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) ~[na:1.7.0_65]

at java.io.BufferedInputStream.read(BufferedInputStream.java:254) ~[na:1.7.0_65]

at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288) ~[na:1.7.0_65]

at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:95) ~[amqp-client-3.6.1.jar:na]

at com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:139) ~[amqp-client-3.6.1.jar:na]

at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:538) ~[amqp-client-3.6.1.jar:na]

... 1 common frames omitted

 

    

      and at this moment, channel.queueDeclare().getQueue() will blocked indefinitely .

     what can i do for this ?

   

       

在 2014年11月14日星期五 UTC+8上午8:03:09，Michael Klishin写道：