Issue Details (XML | Word | Printable)

Key: JMS_SPEC-95
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: chris.barrow
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

Individual message acknowledge mode

Created: 28/Jun/12 05:26 PM   Updated: 23/Jan/14 11:06 AM
Component/s: None
Affects Version/s: 1.1
Fix Version/s: None

Time Tracking:
Not Specified



Tags: jms21-forreview-minor pd20-forreview-major
Participants: chris.barrow, clebertsuconic, John D. Ament, Nigel Deakin and tom.barnes

 Description  « Hide

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.

chris.barrow added a comment - 10/Jul/12 05:08 PM - edited

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.

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).

chris.barrow added a comment - 10/Jul/12 05:16 PM

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).

tom.barnes added a comment - 10/Jul/12 06:26 PM

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.

clebertsuconic added a comment - 19/Sep/13 01:13 PM

This issue should be broken in 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.

Nigel Deakin added a comment - 19/Sep/13 02:08 PM

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)

John D. Ament added a comment - 19/Sep/13 02:12 PM

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

clebertsuconic added a comment - 19/Sep/13 02:19 PM

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

chris.barrow added a comment - 27/Dec/13 08:19 PM

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

Nigel Deakin added a comment - 23/Jan/14 11:06 AM

@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.