Individual message acknowledge mode

[glassfishrobot]

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.

Environment

n/a

Affected Versions

[1.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/95
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by chris.barrow

[glassfishrobot]

@glassfishrobot Commented chris.barrow said: Note that the above use case would require relaxing the threading rules for a Session to allow .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: #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).

[glassfishrobot]

@glassfishrobot Commented chris.barrow said: It is perhaps worth pointing out that allowing the .acknowledge() method to acknowledge only that message would fit in nicely with the proposal to support the acknowledge () method on Session (see issue #68")).

[glassfishrobot]

@glassfishrobot Commented tom.barnes said: 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.

[glassfishrobot]

@glassfishrobot Commented clebertsuconic said: 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.

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: JMS providers which support individual acknowledgement as a non-standard extension:

GlassFish Message Queue http://docs.oracle.com/cd/E18930_01/html/821-2440/aeqef.html#scrolltoc (methods on the provider's message implementation: acknowledgeThisMessage() and acknowledgeUpThroughThisMessage())

ActiveMQ http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQSession.html#INDIVIDUAL_ACKNOWLEDGE (new non-standard acknowledgement mode {[INDIVIDUAL_ACKNOWLEDGE}} which alters the behaviour of Message#acknowledge()

JBoss HornetQ http://docs.jboss.org/hornetq/2.3.0.beta1/docs/user-manual/html/pre-acknowledge.html#individual-ack (new non-standard acknowledgement mode INDIVIDUAL_ACKNOWLEDGE)

[glassfishrobot]

@glassfishrobot Commented genomeprjct said: If we add INDIVIDUAL_ACKNOWLEDGE do we also need to add INDIVIDUAL_ACKNOWLEDGE_TX or equivalent, to individually change to TX mode.

[glassfishrobot]

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

[glassfishrobot]

@glassfishrobot Commented chris.barrow said: Can we get this onto the plan for JMS 2.1? Anything I can do to help?

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: @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.

[glassfishrobot]

@glassfishrobot Commented chris.barrow said: Another JMS provider which supports individual acknowledgement is Tibco EMS: https://docs.tibco.com/pub/enterprise_message_service/6.3.0-february-2012/doc/html/tib_ems_api_reference/api/javadoc/com/tibco/tibjms/Tibjms.html#EXPLICIT_CLIENT_ACKNOWLEDGE (non-standard acknowledgement mode EXPLICIT_CLIENT_ACKNOWLEDGE which alters the behavior of message#acknowledge())

[glassfishrobot]

@glassfishrobot Commented chris.barrow said: I like Clebert's suggestion of CLIENT_INDIVIDUAL_ACKNOWLEDGE. It goes nicely with CLIENT_ACKNOWEDGE,

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: The specification for Session#getAcknowledgementMode and JMSContext#getSessionMode would need to be extended to cover this new feature.

[glassfishrobot]

@glassfishrobot Commented gemmellr said: 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.

[glassfishrobot]

@glassfishrobot Commented mattrpav said: Where does this issue currently stand? It would be great to see this get rolled into 2.1.

[glassfishrobot]

@glassfishrobot Commented akshaygehi said: We use this feature using MQ provider specific implementations too. Would be useful to have this included in the specifications.

[glassfishrobot]

@glassfishrobot Commented vaquarkhan said: 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

https://docs.oracle.com/cd/E19717-01/819-7757/aeqeg/index.html

[glassfishrobot]

@glassfishrobot Commented Issue-Links: is related to JMS_SPEC-176 is related to JMS_SPEC-168 JMS_SPEC-169

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-95