Graham,
Sounds like it is worth fixing.
Cheers,
Reza
On 8/2/2011 7:13 AM, 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.
>
> 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3804 - Release Date: 08/01/11