[
https://issues.apache.org/jira/browse/AMQ-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225212#comment-13225212
]
Timothy Bish commented on AMQ-3760:
-----------------------------------
>From the spec:
"Once a connection has been started, any session with one or more registered
message listeners is dedicated to the thread of control that delivers messages
to it. It is erroneous for client code to use this session or any of its
constituent objects from another thread of control. The only exception to this
rule is the use of the session or connection close method. "
In your test case the first addition of the consumer succeeds which is correct,
after that the session has a running consumer and is subject to the rule that
its invalid for any other thread to call a session method other than close,
which your code does by attempting to create a new consumer from the producer
thread. As per the spec the only Session method that you can safely call from
the producer thread is close() after you create the first consumer as its now
dedicated to the thread that is delivering messages to the consumer.
> Deadlock on Java Client when onMessage executes a synchronized method.
> ----------------------------------------------------------------------
>
> Key: AMQ-3760
> URL: https://issues.apache.org/jira/browse/AMQ-3760
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.5.1
> Environment: java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)
> OS: SunOs 10/06
> Reporter: Alessandro Monguzzi
> Labels: features
> Attachments: ActiveMQDeadlock.zip
>
>
> Create a class with two synchronized methods synchMethod1 and synchMethod2.
> syncMethod1 is invoked inside a messageListener object and only prints a
> message on stdout.
> syncMethod2 creates a new MessageConsumer with a new instance of
> MessageListener. All the MessageConsumers created by synchMethod2 share the
> same session.
> All the consumers listen on the same Topic named "myDest".
> Create an infinite cycle that:
> 1) send a message on Topic "myDest"
> 2) invoke syncMethod2
> 3) waits 10ms
> In attach the unit test source.
> As result, a deadlock is created between the "ActiveMQ Session Task" thread
> entering in syncMethod1 having the ActiveMessageConsumer's mutex and my other
> thread executing the syncMethod2 when the
> SimplePriorityMessageDispatchChannel.stop() method is invoked.
> This means that it's not possible to create or change MessageListeners on a
> running session, even if the code seems to handle this case stopping and
> restarting the session.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira