[rabbitmq-discuss] Queue consumers are blocked on SocketInputStream.socketRead0
tim at rabbitmq.com
Fri Oct 19 15:00:21 BST 2012
On 10/19/2012 03:02 PM, Nicolas Bosansky wrote:
> 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.
> Thanks again,
> 2012/10/19 Tim Watson <tim at rabbitmq.com <mailto:tim at rabbitmq.com>>
> 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:
> 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...
More information about the rabbitmq-discuss