Fair point about the JMS spec; however, ActiveMQ isn't constrained to implement only the minimum required by the spec, and I think this would be a place where there might be value to going beyond the bare minimum required by the spec. I've submitted https://issues.apache.org/jira/browse/AMQ-6098 to propose that enhancement; anyone who's interested in that feature can vote for it in JIRA.
And I'll look into how to submit a bug to the JMS spec board to make it a part of the JMS spec rather than a vendor-specific extension, when I've got the time. Tim On Fri, Dec 11, 2015 at 8:04 AM, Timothy Bish <tabish...@gmail.com> wrote: > 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/ > >
