Skip to main content

[jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes

  • From: Nigel Deakin <nigel.deakin@...>
  • To: users@...
  • Subject: [jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes
  • Date: Thu, 28 Jun 2012 11:22:31 +0100

Chris,

Thanks for the interesting suggestions. Could you please open a new issue in the JMS spec JIRA for this?
http://java.net/jira/browse/JMS_SPEC

I'd like to clear the existing backlog of started-but-incomplete features before we consider new ones, but I don't want to lose this idea. More comments below...

(N.B. Anyone else reading this is very welcome to join in)

On 28/06/2012 06:36, Chris Barrow wrote:
Hi all,

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 confusing, it is highly inconvenient in cases where message processing is being done by multiple threads asynchronously.

Hmm. If the application is consuming messages in different threads at the same time then shouldn't it be using different sessions?

I realise this can be overcome to some degree by using multiple MessageConsumers on separate Sessions, but that imposes more of an 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 multithreaded or asynchronous processing of messages much easier to implement.

This sounds reasonable, but I think we would need to explore that you mean by multi-threaded processing of messages so we can be sure that the use case you have in mind can be supported without breaking the threading restrictions on a session.

Over in Java EE, where messages from a destination are being processed by a pool of MDB instances, then we do have multi-threaded processing of messages. If the MDB is configured to use container-managed transactions then a transaction commit covers an individual message only, which sounds a bit like what you have in mind. Interestingly, though, the EJB spec doesn't allow client acknowledgement in MDBs. I wonder why.


One can imagine other acknowledge modes that could 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.

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.

thanks,
Chris Barrow

Nigel


[jms-spec users] JMS 2.0: enhancement request: more flexible acknowledgment modes

Chris Barrow 06/28/2012

[jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes

Nigel Deakin 06/28/2012

[jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes

Chris Barrow 06/28/2012

[jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes

Nigel Deakin 06/29/2012

[jms-spec users] Re: JMS 2.0: enhancement request: more flexible acknowledgment modes

Chris Barrow 06/29/2012
 
 
Close
loading
Please Confirm
Close