activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: How to use INDIVIDUAL_ACKNOWLEDGE mode?
Date Sun, 20 Dec 2015 06:54:53 GMT
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 <tabish121@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 <tabish121@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.bish@redhat.com | www.redhat.com
> >> twitter: @tabish121
> >> blog: http://timbish.blogspot.com/
> >>
> >>
>
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message