[rabbitmq-discuss] Queue consumers are blocked on SocketInputStream.socketRead0
tim at rabbitmq.com
Fri Oct 19 14:08:59 BST 2012
Please do not use the google group, as we do not own or subscribe to it.
In terms of your question, please see my comments inline (below).
On 10/18/2012 04:50 PM, Nicolas Bosansky wrote:
> We have a rabbitMQ consumer that takes messages from a queue and write
> them in a HBase store.
> When HBase connection fails, the consumer get an exception and
> messages are not acknowledged, that's ok.
> After a few minutes, the consumer doesn't get messages anymore, even
> after restarting Hbase.
Firstly, I don't really understand what you're describing here. What
does the HBase connection failure have to do with the rabbitmq consumer?
Are you saying that the HBase connection failure causes an unhandled
exception on the thread which the consumer is running in? What does this
have to do with acks - are you saying that your client code does not ack
messages which arrive that cannot be written to HBase? That's fine, but
you ought to nack/reject them unless you're hanging on to them
deliberately in order to deal with them later on. Perhaps this is what
is causing the problem?
"If a consumer dies without sending an acknowledgement the AMQP broker
will redeliver it to another consumer or, if none are available at the
time, the broker will wait until at least one consumer is registered for
the same queue before attempting redelivery." -
So if you do not ack the messages you've already received *nor*
nack/reject them, then you're not going to get any more messages until
you do? Am I missing something here, or are you just not instructing the
broker that you're ready to continue consuming from the queue (by
dealing with the messages it has already sent you which need to be
ack'ed or rejected)?
> When debugging rabbitMQ client, we have noticed, that it is blocked on
> the following line: SocketInputStream:129 ( Java build 1.6.0_33-b03)
> The Frame class is waiting for messages, but the used socket doesn't
> receive any data anymore.
> We also notice, that there is no timeout on this socket.
There isn't meant to be a timeout when reading frames.
More information about the rabbitmq-discuss