我们有Clojure代码,它从Rabbit队列中读取。我们想要容忍RabbitMQ服务器短暂停机的情况,例如:在重新启动的情况下(sudo service rabbitmq-server restart
)。
Langohr似乎有some provision for reconnecting。我们调整了示例clojurewerkz.langohr.examples.recovery.example1
(Gist here)。与已发布的示例相比略有差异,包括连接参数和lb/publish
调用的删除(因为我们正在使用外部源填充数据)。
我们可以成功使用队列中的数据并等待更多消息。但是,当我们重新启动RMQ时(通过托管RabbitMQ的VM上面的sudo
命令),抛出以下异常:
Caught an exception during connection recovery!
java.io.IOException
at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:106)
at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:102)
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:378)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:516)
at com.rabbitmq.client.ConnectionFactory.newConnection(ConnectionFactory.java:545)
at com.novemberain.langohr.Connection.recoverConnection(Connection.java:166)
at com.novemberain.langohr.Connection.beginAutomaticRecovery(Connection.java:115)
at com.novemberain.langohr.Connection.access$000(Connection.java:18)
at com.novemberain.langohr.Connection$1.shutdownCompleted(Connection.java:93)
at com.rabbitmq.client.impl.ShutdownNotifierComponent.notifyListeners(ShutdownNotifierComponent.java:75)
at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:573)
Caused by: com.rabbitmq.client.ShutdownSignalException: connection error; reason: java.io.EOFException
at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:67)
at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:33)
at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:343)
at com.rabbitmq.client.impl.AMQConnection.start(AMQConnection.java:321)
... 8 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:273)
at com.rabbitmq.client.impl.Frame.readFrom(Frame.java:95)
at com.rabbitmq.client.impl.SocketFrameHandler.readFrame(SocketFrameHandler.java:131)
at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:533)
Langohr提供的预期重启机制似乎很可能在它启动时破坏。是否有一种替代模式在这些情况下是首选的?" hard"重新启动?或者,我想我们必须实现连接监视并重试自己。任何建议都是最受欢迎的。
答案 0 :(得分:2)
我们曾经看过这样的堆栈跟踪,但我们不再使用Langohr 2.9.0看到它们。重启后,我们的clojure客户端重新连接,消息再次开始流动。
我们使用的默认设置已启用连接和拓扑覆盖,如下所示:
(infof "Automatic recovery enabled? %s" (rmq/automatic-recovery-enabled? connection))
(infof "Topology recovery enabled? %s" (rmq/automatic-topology-recovery-enabled? connection))