Nigel,
Thanks, I have added a note to the JIRA (JMS_SPEC-95
<
http://java.net/jira/browse/JMS_SPEC-95>).
Chris
On 7/9/2012 11:12 AM, Nigel Deakin wrote:
> 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
>>>>
>>>>
>>
>>