[JMS_SPEC-95] Individual message acknowledge mode Created: 28/Jun/12  Updated: 27/Jul/16

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: chris.barrow Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Issue Links:
is related to JMS_SPEC-176 Allow message acknowledgment outside ... Open
is related to JMS_SPEC-168 No-acknowledge mode Open
is related to JMS_SPEC-169 Vendor-defined acknowledgement modes Open
Tags: jms21-forreview-minor, pd20-forreview-major


Currently the JMS 1.1 and 2.0 specifications only allow for one mode of operation for applications which wish to do their own message acknowledgment. This is CLIENT_ACKNOWLEDGE mode. This mode has the following characteristic, as defined in the spec: "Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session.".

This Implicit acknowledgment of all messages is not only somewhat unexpected, because it's such a broad side effect, it is highly inconvenient in cases where message processing is being done by multiple threads asynchronously (message reception on one Session has to be in a single thread, per JMS spec rules, but I am talking about cases where the messages are then dispatched to one or more worker threads, or even other processes, for asynchronous processing). I realise this can be overcome to some degree by using a separate Session and MessageConsumer in each worker thread, but that imposes more overhead on the JMS provider. A better alternative, which is already offered by certain JMS providers (including Tibco EMS and ActiveMQ), is INDIVIDUAL_ACKNOWLEDGE mode, where acknowledging a message acknowledges only that message. This makes asynchronous processing of messages much easier to implement.

One can imagine other acknowledge modes that would be useful too, for example: CONSUMER_ACKNOWLEDGE where Message.acknowledge() would acknowledge only messages received up on a particular MessageConsumer, or CONSUMER_CHECKPOINT_ACKNOWLEDGE where Message.acknowledge() would acknowledge only messages received up to and including the Message instance on which the method was called.

But without embarking on all these various different possibilities, would it be possible to consider just adding INDIVIDUAL_ACKNOWLEDGE mode? This alone would make it possible for multithreaded applications to achieve whatever behaviors they need.

Comment by chris.barrow [ 10/Jul/12 ]

Note that the above use case would require relaxing the threading rules for a Session to allow <Message>.acknowledge() to be called in threads other than the JMS provider thread which is delivering messages, at least in the case where INDIVIDUAL_ACKNOWLEDGE mode is set on the session. So it would be desirable to include that relaxation along with this feature. I have now filed a separate ticket for this: JMS_SPEC-176: Allow message acknowledgment outside of the message delivery thread.

The relevant parts of the JMS 1.1 spec are 4.4 "Session" which states (in a footnote) that "the restriction is that the resources of a Session should not be used concurrently by multiple threads" and section 4.4.6 "Conventions for Using a Session" which explains "Once a connection has been started, all its sessions with a registered message listener are dedicated to the thread of control that delivers messages to them.".

Currently the only exception to this rule is that the Session.close method may be called outside the thread of control. The feature described by this ticket would require an additional exception: that the Message.acknowledge() method can be called outside the thread of control (at least when the session acknowledge mode is INDIVIDUAL_ACKNOWLEDGE).

Comment by chris.barrow [ 10/Jul/12 ]

It is perhaps worth pointing out that allowing the <Message>.acknowledge() method to acknowledge only that message would fit in nicely with the proposal to support the acknowledge () method on Session (see issue JMS_SPEC-68).

Comment by tom.barnes [ 10/Jul/12 ]

A potential alternate API to the proposed new acknowledge modes INDIVIDUAL_ACKNOWLEDGE and CONSUMER_CHECKPOINT_ACKNOWLEDGE could be new Session methods “acknowledgeOne(Message)” and “acknowledgeUpThrough(Message)”. These new methods, like the current "message.acknowledge()" and the proposed "session.acknowledge()", would only apply in CLIENT_ACKNOWLEDGE mode.

This would eliminate the need to add new acknowledge modes, and would preserve the semantics of the old "acknowledge()" verb so that it always had the same legacy behavior.

Comment by clebertsuconic [ 19/Sep/13 ]

This issue should be broken in two...one about INDIVIDUAL_ACKNOWLEDGE which is already implemented in a few implementation (I know for instance both hornetQ and ActiveMQ have it).

I'm ok with INDIVIDUAL_ACKNOWLEDGE... but I feel session.acknowledge() is a bit not doable.

by adding INDIVIDUAL_ACKNOWLEDGE mode you can change the semantic of message.acknowledge() as most providers already do. It's a minor change in semantic anyways as you only ack that message which is exactly what the user would expect in such case.

Of course this would only apply to non-transactional, same way as the CLIENT_ACKNOWLEDGE is done. INDIVIDUAL_ACKNOWLEDGE would just be a different CLIENT_ACK mode.

you could even maybe call it CLIENT_INDIVIDUAL_ACKNOWLEDGE but I guess a short name woud be better... INDIVIDUAL_ACKNOWLEDGE.

Comment by Nigel Deakin [ 19/Sep/13 ]

JMS providers which support individual acknowledgement as a non-standard extension:

GlassFish Message Queue
(methods on the provider's message implementation: acknowledgeThisMessage() and acknowledgeUpThroughThisMessage())

(new non-standard acknowledgement mode {[INDIVIDUAL_ACKNOWLEDGE}} which alters the behaviour of Message#acknowledge()

JBoss HornetQ
(new non-standard acknowledgement mode INDIVIDUAL_ACKNOWLEDGE)

Comment by John D. Ament [ 19/Sep/13 ]

If we add INDIVIDUAL_ACKNOWLEDGE do we also need to add INDIVIDUAL_ACKNOWLEDGE_TX or equivalent, to individually change to TX mode.

Comment by clebertsuconic [ 19/Sep/13 ]

@John D. Ament: quick answero: no... there's no directly ack on messages on any TX mode. so no reason for that

Comment by chris.barrow [ 27/Dec/13 ]

Can we get this onto the plan for JMS 2.1? Anything I can do to help?

Comment by Nigel Deakin [ 23/Jan/14 ]

@Chris: Yes, I've just added it to that page (and added an appropriate tag). Thanks for spotting that this issue was in danger of being forgotten. This put the issue on the agenda for formal discussion for 2.1 - nothing has been decided yet.

Comment by chris.barrow [ 08/Jul/14 ]

Another JMS provider which supports individual acknowledgement is Tibco EMS:
(non-standard acknowledgement mode EXPLICIT_CLIENT_ACKNOWLEDGE which alters the behavior of message#acknowledge())

Comment by chris.barrow [ 22/Jan/15 ]

I like Clebert's suggestion of CLIENT_INDIVIDUAL_ACKNOWLEDGE. It goes nicely with CLIENT_ACKNOWEDGE,

Comment by Nigel Deakin [ 27/Feb/15 ]

The specification for Session#getAcknowledgementMode and JMSContext#getSessionMode would need to be extended to cover this new feature.

Comment by gemmellr [ 14/Oct/15 ]

Individual acknowledgement of messages would seem to be a useful thing to support. There is work ongoing on a AMQP mapping for JMS over at OASIS, and individual acknowledge is an area of functionality that there isn't currently a natural fit for in JMS. Supporting this would also allow enabling the behaviour I have seen several people actually think the existing method had until they use it and discover otherwise; the javadoc is perfectly clear on the behaviour of course, but requires that they read it first.

Between the mentioned routes for implementation thus far, I would personally prefer the route of adding a new ack mode such as CLIENT_INDIVIDUAL_ACKNOWLEDGE and using it to govern the behaviour of Message#acknowledge(). This seems the most intuitive to me given it is a different mode of acknowledgement, the acknowledge action is on the message, and doing so would enable the kind of behaviour that people often think is already offered by the method. From above, it also seems to be how more of the existing vendor extensions approach offering the functionality.

Comment by mattrpav [ 25/Apr/16 ]

Where does this issue currently stand? It would be great to see this get rolled into 2.1.

Comment by akshaygehi [ 27/Jul/16 ]

We use this feature using MQ provider specific implementations too. Would be useful to have this included in the specifications.

Comment by vaquarkhan [ 27/Jul/16 ]

Individual message acknowledge mode feature provided by most of the messaging provider and it's also available in Sun Java System Message Queue 4.1


Generated at Tue Sep 27 00:10:02 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.