Hi, 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. Thanks again, Nicolas 2012/10/19 Tim Watson <[email protected]> > 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<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. > -- You received this message because you are subscribed to the Google Groups "rabbitmq-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rabbitmq-discuss?hl=en.
