[rabbitmq-discuss] Queue consumers are blocked on SocketInputStream.socketRead0
nicolas.bosansky at gmail.com
Fri Oct 19 15:02:30 BST 2012
Thanks for your response and sorry for using google groups.
We just have found why we don't get messages anymore from the broker.
Your explanation corresponds exactly to our problem : when Hbase connection
fails, it generates an exception, and in this case, we don't 'ack' nor
'nack/reject' the message.
Now, we nack the message when something wrong occurs and so we get the next
messages from the queue.
2012/10/19 Tim Watson <tim at rabbitmq.com>
> 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." - http://www.rabbitmq.com/**
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss