Graham,
On 02/08/2011 16:45, Graham Wallis wrote:
>
> I think that prohibiting MessageListener from calling the above methods
> would be desirable, but I'm worried about introducing a compatibility
> issue. For a situation where the MessageListener really does need to cause
> connection to stop, it may be better to specify an onMessage with a
> non-void return type or recommend some non-blocking operation on the
> connection that sets a condition that the connection must check on
> completion of onMessage(). Neither is attractive, but nor is the current
> situation.
>
Let's see what the 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.
>
> I read that to mean that the Connection will invoke the ExceptionListener
> on one thread at a time; but I guess this still permits other threads to be
> performing work, because the connection would only need to synchronise the
> invocation of ExceptionListener.
Perhaps it means that if you register the same ExceptionListener instance with multiple connections, and several
connections fail at the same tine (which is quite likely), only one connection will invoke onException at a time.
> But I think the serialisation of the calls
> to ExceptionListener may not be the issue here - I think it arises because
> a JMS provider can invoke the ExceptionListener whilst the provider is in a
> receive for example; and if the ExceptionListener invokes connection.stop()
> you get a similar deadlock to the MessageListener one above - i.e. the stop
> won't return until all receive threads have returned; and one of them
> cannot because it's waiting for the ExceptionListener to return.
If a connection detects a problem and calls the ExceptionListener, I don't see why this should cause a call to receive()
in some other thread to block. Can you clarify why you think this is the case?
If there were a problem with the connection, then receive() could throw a (different) exception anyway.
Nigel
>
>>
>> Nigel
>>