Claire Fautsch
2014-03-03 08:18:06 UTC
Hi,
we have following issue with blocking queues:
Once the memory watermark is reached, the connection from the client gets
blocked by the RabbitMQ server and it is no longer possible to publish
messages.
If this happens, we are for some time still able to publish messages,
however they remain in the socket's write buffer and are not actually
published until the connection is un-blocked again. Once this buffer is
full, publishing blocks completely.
After some research we found out, that with a newer version of the official
Java client, it is possible to use blocked connection notifications to
react on this situation.
Our prefered reaction would be to close the connection, and re-connect to
another broker. Here however comes the problem: It is not possible to close
the connection to the RabbitMQ, as the method to do so, involves a flush on
the socket before the socket is closed and this is blocked as well.
Is there any possibility for a force-closed on the client side? Or is the
only possibility to open a new connection without closing the old one, and
"let it die"?
Re-writing the SocketFrameHandler would of course also be a possibility,
but one we would (if possible) like to avoid. (see also discussion here :
https://github.com/rabbitmq/rabbitmq-java-client/issues/11)
Additionally, when we see blocking connections occurring, we frequently see
following stack trace in our logs, where we are not absolutely sure where
it comes from, or rather why it occurs
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:37)
at
com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:349)
at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:569)
at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:501)
...
Caused by: java.io.EOFException
at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:494)at
java.io.DataInputStream.readUnsignedByte(Unknown Source)
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:515)
For information, we are currently using Java client,
com.rabbitmq:amqp-client version 3.1.4
and com.zanox.lib.rabbiteasy version:rabbiteasy-core version 1.2.0, for the
connection handling (SingleConnectionFactory) and publishing.
Thanks in advance for any hint or ideas.
Regards
Claire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140303/0218e162/attachment.html>
we have following issue with blocking queues:
Once the memory watermark is reached, the connection from the client gets
blocked by the RabbitMQ server and it is no longer possible to publish
messages.
If this happens, we are for some time still able to publish messages,
however they remain in the socket's write buffer and are not actually
published until the connection is un-blocked again. Once this buffer is
full, publishing blocks completely.
After some research we found out, that with a newer version of the official
Java client, it is possible to use blocked connection notifications to
react on this situation.
Our prefered reaction would be to close the connection, and re-connect to
another broker. Here however comes the problem: It is not possible to close
the connection to the RabbitMQ, as the method to do so, involves a flush on
the socket before the socket is closed and this is blocked as well.
Is there any possibility for a force-closed on the client side? Or is the
only possibility to open a new connection without closing the old one, and
"let it die"?
Re-writing the SocketFrameHandler would of course also be a possibility,
but one we would (if possible) like to avoid. (see also discussion here :
https://github.com/rabbitmq/rabbitmq-java-client/issues/11)
Additionally, when we see blocking connections occurring, we frequently see
following stack trace in our logs, where we are not absolutely sure where
it comes from, or rather why it occurs
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:37)
at
com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:349)
at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:569)
at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:501)
...
Caused by: java.io.EOFException
at com.rabbitmq.client.impl.ChannelN.close(ChannelN.java:494)at
java.io.DataInputStream.readUnsignedByte(Unknown Source)
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:515)
For information, we are currently using Java client,
com.rabbitmq:amqp-client version 3.1.4
and com.zanox.lib.rabbiteasy version:rabbiteasy-core version 1.2.0, for the
connection handling (SingleConnectionFactory) and publishing.
Thanks in advance for any hint or ideas.
Regards
Claire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140303/0218e162/attachment.html>