[rabbitmq-discuss] Queue consumers are blocked on SocketInputStream.socketRead0

[Tim Watson]

Hi

Please do not use the google group, as we do not own or subscribe to it. 
Thanks!

In terms of your question, please see my comments inline (below).

On 10/18/2012 04:50 PM, Nicolas Bosansky wrote:
> Hello,
> 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/tutorials/amqp-concepts.html

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.