Thanks. That's great. I've added an approriate tag to help me track
it and added it to the "new issues" list at
Since we already have a backlog of unfinished issues I'd like to
defer formal consideration of this until later, but if anyone has
any immediate comments on this please use the reply button or add
them to the JIRA issue. It's likely we won't have time to consider
this properly for JMS 2.0, which is why I want to make sure it is
captured properly in JIRA.
You refer to dispatching received messages to other threads for
processing. Were you envisaging that the calls to acknowledge each
message would be serialised (since this counts as "using the
resources of the session")?
On 28/06/2012 18:51, Chris Barrow wrote:
I have filed it as JMS_SPEC-95
I clarified about the threading in the wording of the issue. but
to summarize, I meant that there is a single thread receiving
messages (as required by the spec) but they are then dispatched
to other threads or even other processes across the network for
asynchronous processing. The order in which the messages will be
processed and therefore acknowledged is unpredictable, hence the
need to acknowledge them individually. Certain messages may fail
to be processed and need to be redelivered ("NACKed") by closing
or resetting the Session.
On 6/28/2012 3:22 AM, Nigel Deakin wrote:
Thanks for the interesting suggestions. Could you please open a
new issue in the JMS spec JIRA for this?
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:
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
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