On 12/11/2015 09:56 AM, Tim Bain wrote: > Tim, > > What I understand from your answer is that no, there is no way for a > consumer that has consumed (but not yet acked) more than one message to > nack only one of them while remaining connected and continuing to consume. > Both options you mentioned involve nacking all unacked messages, which > might not be possible for a consumer if there are always messages that are > in the middle of (successfully) processing. > > If what I said is accurate, is there a reason that that's how the feature > has been implemented? On the surface, this seems like a gaping hole in the > functionality of the feature (and that a bug should be submitted against > it); is there something I'm overlooking about the feature or the valid use > cases for it that make the current implementation complete despite how it > looks from a cursory glance?
If you want to submit a bug to the JMS Spec board to supply a method of NACK'ing that's a good place to start, since there is no API to NACK a message in JMS your two options are, throw on the messages you don't want, or ack and close. I forget exactly how things behave when a TX is also in use but I think the original question mentioned that he tried it and it didn't match what he was hoping for in behavior due to redelivery semantics. > > Tim > > On Tue, Dec 8, 2015 at 2:59 PM, Timothy Bish <tabish...@gmail.com> wrote: > >> On 12/08/2015 04:44 PM, Camilo Rostoker wrote: >>> Hi all, >>> >>> I'm trying to understand how to use the INDIVIDUAL_ACKNOWLEDGE mode >>> properly. >>> >>> What I am trying to do is this: >>> >>> 1. Message Producer sends messages to a queue >>> 2. Message Consumer receives individual message and confirms successful >>> processing of each individual message. >>> 3. If Message Consumer cannot successfully process the message, then it >>> should be re-delivered automatically according to the re-delivery policy. >>> >>> >>> My question is this: How is the _unsuccessful_ processing of a message >>> communicated to the ActiveMQ broker? The only way I've been able to do >>> this is to explicitly throw some kind of RuntimeException, but this seems >>> hacky. >> Throwing is one option, otherwise closing the consumer will cause all >> unack'd messages to be redelivered to another consumer. >> >>> I have almost been able to get this working using the transactional queue >>> approach, to explicitly commit or rollback an individual message, but >> this >>> then causes the message redelivery mechanism to re-send messages using >>> incorrect schedule. >>> >>> Any help is greatly appreciated. >>> >>> Thanks! >>> Cam >>> >> >> -- >> Tim Bish >> Sr Software Engineer | RedHat Inc. >> tim.b...@redhat.com | www.redhat.com >> twitter: @tabish121 >> blog: http://timbish.blogspot.com/ >> >> -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
