activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: How to use INDIVIDUAL_ACKNOWLEDGE mode?
Date Fri, 11 Dec 2015 15:04:34 GMT
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

> Tim
> On Tue, Dec 8, 2015 at 2:59 PM, Timothy Bish <> 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.
>> |
>> twitter: @tabish121
>> blog:

Tim Bish
Sr Software Engineer | RedHat Inc. | 
twitter: @tabish121

View raw message