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?

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

Reply via email to