Allow message acknowledgment outside of the message delivery thread

[glassfishrobot]

Several vendors currently support individual message acknowledgment outside of message listeners, that is, on a thread other than the thread of control of the Session. This is useful for certain types of application, for example, the asynchronous processing of queue or durable topic subscriber messages (for which individual message acknowledgment would also be useful, see #95).

The fact that several vendors already support this usage demonstrates the value of this feature.

It is therefore proposed to alter the JMS specification to explicitly allow message acknowledgment from a thread other than the message delivery thread of the Session that runs the MessageListeners. Currently the only Session-related methods which are allowed to be called outside of the thread of control of the Session are Session.close and Consumer.close (JMS 2.0 spec section 6.5). The proposed enhancement would add the Message.acknowledge method to this list when individual message acknowledge mode is being used (see #95).

Affected Versions

[1.1]

[glassfishrobot]

@glassfishrobot Commented
Reported by chris.barrow

[glassfishrobot]

@glassfishrobot Commented
Issue-Links:
is related to
JMS_SPEC-95

[glassfishrobot]

@glassfishrobot Commented
chris.barrow said:
Here's a comment from Tom Barnes (email 22-Oct-15):

It looks like there’s at least one race condition to consider for #176: With classic CLIENT_ACKNOWLEDGE, a non-onMessage-thread msg.acknowledge() call could unintentionally acknowledge a message that happens to arrive in the onMessage callback after the message being acknowledged. This is due to the spec requirement taht an ack() call must ack all of a session’s received messages - even those received after the message being acknowledged. I think this means that the proposed multi-threading supported should be limited to the proposed new ‘ack this message’ and ‘ack up to this message’ APIs.

[glassfishrobot]

@glassfishrobot Commented
chris.barrow said:
I have amended the issue description in view of the above comment.

[glassfishrobot]

@glassfishrobot Commented
chris.barrow said:
Notes from an email discussion with Nigel Deakin
(Nigel)
If you need to be able to receive a message using a MessageListener but acknowledge it in a different thread, then does this mean you want to call other methods on the Message object (e.g. getting the message body, headers etc) in the other thread?
(Chris)
For our use case we do not need to call other methods on the Message object in the other thread. What we are doing is writing the message in an encoded form onto a WebSocket connection so that a client can process it and reply with an ACK frame which is then used to acknowledge the message outside of the message listener. Basically we are extending JMS to work on web clients via WebSocket. I think this is an interesting use case with other people may want to do (or may even already be doing), and this sort of usage could add value to JMS. I did give a presentation on this architecture with a colleague at JavaOne back in 2011. But the feature could apply to any sort of asynchronous processing of messages that need to be acknowledged.
(Nigel)
Right. So it really is just the ack that's in a different thread.
However I think that once we allow individual acks, and allow messages to be acked in a thread other than the listener thread, users will also want to do more of the message processing in a different thread as well. (Though some people may want to argue this is allowed anyway anyway).

[glassfishrobot]

@glassfishrobot Commented
clebertsuconic said:
I'm also a bit concerned about this... it breaks the Session = Thread contract defined by the Spec. It will require extra synchronizations to make such thing happen and vendors who optimized performance on client.ack will be affected by this.

If you synchronize everything is fine.. but if you favour high performance.. this can be affected as it clashes with the spec as mentioned by Tom Barnes.

[glassfishrobot]

@glassfishrobot Commented
chris.barrow said:
I would think it should be possible to implement this without use of synchronization. For example, if the session message dispatcher thread is driven by a blocking input event (incoming message) queue, it should be possible just to post the acknowledge request onto that queue so it gets executed by the same thread that is delivering the messages. That would then be equivalent to current usage where message.acknowledge() is always called from a message listener.

[glassfishrobot]

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

[glassfishrobot]

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