Chris,
I think the relevant sections 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."
So once a message listener is registered (and the connection started) it is illegal to "use the resources of the
session" from any other thread. This isn't about the use of the Session object itself. As an example, the spec explains
that calling MessageConsumer.receive() from another thread would be illegal, even though this doesn't use the Session
object. So I'm pretty sure that calling Message.acknowledge() would also be illegal from any other thread.
Of course, if we invent a new feature we can specify whatever threading rules we want - though we need to avoid defining
rules which it would be difficult for existing providers to support.
For now, I would suggest adding a note to the JIRA issue that mentions this topic.
Nigel
On 29/06/2012 21:25, Chris Barrow wrote:
> Nigel,
>
> Yes, the calls to acknowledge each message (coming from the same session) would be serialized. I will update the JIRA
> ticket to make that clear. But your question has made me start wondering if that is sufficient to respect the rules
> about Session being a single threaded object. Section "2.8 multi-threading" of the spec does not mention the Message
> object in its table of JMS objects that (do or do not) support concurrent use. So it's not very clear what the rules
> are for calling acknowledge() on a Message. If there are message listeners on a Session, is it valid to call
> <Message>.acknowledge at all outside of the message listeners? In practice those JMS providers I have worked with do
> seem to allow this.
>
> thanks,
> Chris
>
> On 6/29/2012 2:30 AM, Nigel Deakin wrote:
>> Chris,
>>
>> Thanks. That's great. I've added an approriate tag to help me track it and added it to the "new issues" list at
>> http://java.net/projects/jms-spec/pages/JSR343Planning#Priority_3:_New_issues
>>
>> 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")?
>>
>> Nigel
>>
>>
>> On 28/06/2012 18:51, Chris Barrow wrote:
>>> Hi Nigel,
>>>
>>> I have filed it as JMS_SPEC-95 <http://java.net/jira/browse/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.
>>>
>>> Chris
>>>
>>> On 6/28/2012 3:22 AM, Nigel Deakin wrote:
>>>> 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
>>>
>>>
>
>