I'd like to revisit an old issue that we discussed back in January
Specify that Connection.stop() or Connection.close() may not be called from a
This concerned the behaviour when calling Connection.close() or
Connection.stop() from a MessageListener (where
MessageListener is being used to consume messages from that connection).
JMS 1.1 specified that Connection.stop() and Connection.close() should not
returned until any calls to onMessage() had
returned. If these methods were called from onMessage() itself then they
would never return, causing deadlock.
We therefore agreed to specify that if Connection.stop(), Connection.close(),
JMSContext .stop() or JMSContext .close()
were called by a MessageListener on its own Connection then a
IllegalStateException would be thrown.
Since this was added to the spec it has been pointed out that a similar issue
applies with the close() methods on
Session and MessageConsumer. In JMS 1.1 the API docs for these methods states that
"This call blocks until a receive or
message listener in progress has completed.".
I would therefore like to propose that we amend the definition of
Session.close(), MessageConsumer.close() and
JMSConsumer.close() to match Connection.stop(), Connection.close(),
JMSContext.stop() and JMSContext.close(), and state
" A message listener associated with a MessageConsumer must not attempt to
close its own Connection, Session or
MessageConsumer as this would lead to deadlock. For the same reason a message
listener associated with a JMSConsumer
must not attempt to close its own JMSContext or JMSConsumer. The JMS provider
must detect these cases and throw a
Any comments? I think this is just an oversight (I'm not sure why I missed
this!) and so I will go ahead and draft the
appropriate spec changes.
[jms-spec users] [jsr343-experts] Re: (JMS_SPEC-48) Specify that connection.stop() or close() may not be called from a MessageListener