Graham,
On 02/08/2011 12:13, Graham Wallis wrote:
>
> 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.
Very good issue. I suppose the first question to ask is whether stop() may be called from onMessage(), irrespective of
what is going on in other threads.
As the spec is currently written, the call to stop() cannot return until all MessageListeners have returned, but if the
call to stop() is itself being performed from a MessageListener then this will never happen.
Do you a suggestion? I am tempted to say that a MessageListener should not call connection.stop(), or connection.close,
or session.close(). What do others think?
>
> 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.
Hmm. What does "a Connection serializes execution of its ExceptionListener" (in 4.3.8) mean, in your view? Given that a
Connection isn't associated with a particular thread, it's not immediately obvious to me what is meant to be blocked
until onException() returns.
Nigel