Nigel et al,
I wanted to bring this up for discussion to see whether others recognise
these problems and to see whether other people think they are worth
addressing.
In the current JMS 1.1 specification, there are various inconsistencies
that, if interpreted literally, can lead to deadlocks. My belief is that
most/all providers will have taken steps to circumvent the problems, but it
would be desirable to clean up the spec.
The first example is in asynchronous consume:
If an implementation of javax.jms.MessageListener calls Connection.stop()
the wording of the current spec can lead to a deadlock. From JMS 1.1
chapter 4.3.4: "If MessageListeners are running when stop is invoked, stop
must wait until all of them have returned before it may return. While these
MessageListeners are completing, they must have the full services of the
connection available to them.” If the "full services" can reasonably be
interpreted to include calling the stop() method itself, the system will
deadlock.
The second example is in exception listeners:
A Connection serializes execution of its ExceptionListener, and if the
ExceptionListener attempts to stop the Connection, this will result in
deadlock.
It is probably worth clarifying what an ExceptionListener is permitted to
do.
Best regards,
Graham