I'd like to revisit an old issue that we discussed back in January
http://java.net/jira/browse/JMS_SPEC-48
Specify that Connection.stop() or Connection.close() may not be called from a MessageListener
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
that:
" 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
IllegalStateException."
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.
Thanks,
Nigel