On Mon, May 10, 2010 at 3:53 AM, jid1jid1 <j...@dharma.gr> wrote:
>
> Apologies for not raising an issue with jira (need time to login and as
> always running for deadlines. I have attached a draft Unit test that
> basically shows that a deadlock will occur if one message listener does not
> return (ie. a MessageListener will not get interupted when we ask for a
> session to close). Not sure if this is supposed to be like that on not by
> JMS Spec. (If I have some time later, I will properly update this issue)
In the JMS spec, section 4.4.14 Serial Execution of Client Code it states:
'To receive messages asynchronously, a client registers an object that
implements the JMS MessageListener interface with a MessageConsumer.
In effect, a Session uses a single thread to run all its
MessageListeners. While the thread is busy executing one listener, all
other messages to be asynchronously delivered to the session must
wait.'
So this places a requirement on the MessageListener that it be
thread-safe. This requirement from the JMS spec is similar to the
requirement for servlets from the servlet spec that says a servlet
must be thread-safe. It's the job of the developer to implement a
thread-safe client that does not misbehave. Locking indefinitely would
be an example of misbehavior. There is nothing in the JMS spec stating
that the Session should make up for such bad behavior, but there is no
reason that a misbehaving MessageListener couldn't be forcibly closed
if it is causing the execution to hang (e.g., perhaps beyond a given
timeout period).
Bruce
--
perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
