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

[Tim Watson]

Hi

On 10/19/2012 03:02 PM, Nicolas Bosansky wrote:
> Hi,
>
> Thanks for your response and sorry for using google groups.
>

Ok no probs, I don't want you to think I'm telling you off! :D

> 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.
>

Awesome - glad it works for you now.

Cheers,
Tim

> Thanks again,
> Nicolas
>
>
> 2012/10/19 Tim Watson <tim at rabbitmq.com <mailto:tim at rabbitmq.com>>
>
>     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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121019/eb9a75c3/attachment.htm>