Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SingleConnectionFactory's resetConnection is causing deadlocks with underlying OracleAQ's JMS connection [SPR-5987] #10655

spring-projects-issues opened this issue Aug 6, 2009 · 3 comments
in: messaging type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Aug 6, 2009

Rajani Chennamaneni opened SPR-5987 and commented

We had encountered below deadlock using the Spring 2.5.6 jar.

"DefaultMessageListenerContainer-303263" prio=10 tid=0x081be000 nid=0x5e74 waiting for monitor entry [0xb0698000..0xb0698ea0]
java.lang.Thread.State: BLOCKED (on object monitor)
at oracle.jms.AQjmsExceptionListener.resumeExceptionListener(

  • waiting to lock <0x56154178> (a oracle.jms.AQjmsExceptionListener)
    at oracle.jms.AQjmsConnection.start(
  • locked <0x5614ec28> (a oracle.jms.AQjmsConnection)
    at org.springframework.jms.connection.SingleConnectionFactory$SharedConnectionInvocationHandler.invoke(
    at $Proxy29.start(Unknown Source)
    at org.springframework.jms.connection.ConnectionFactoryUtils.doGetTransactionalSession(
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(
    at org.springframework.jms.listener.DefaultMessageListenerContainer$

"Thread-336" prio=10 tid=0x0852e800 nid=0x489e waiting for monitor entry [0xaf0b0000..0xaf0b10a0]
java.lang.Thread.State: BLOCKED (on object monitor)
at oracle.jms.AQjmsConnection.stop(

  • waiting to lock <0x5614ec28> (a oracle.jms.AQjmsConnection)
    at org.springframework.jms.connection.SingleConnectionFactory.closeConnection(
    at org.springframework.jms.connection.SingleConnectionFactory.resetConnection(
  • locked <0x5556c840> (a java.lang.Object)
    at org.springframework.jms.connection.CachingConnectionFactory.resetConnection(
    at org.springframework.jms.connection.SingleConnectionFactory.onException(
    at org.springframework.jms.connection.ChainedExceptionListener.onException(
    at oracle.jms.AQjmsExceptionListener.onException(
  • locked <0x56154178> (a oracle.jms.AQjmsExceptionListener)

We then patched for the change made in Revision 1500 ( of this class in truck in our project. I will attach the patched file to this issue as well. This patch we did also includes an additional log statement in "onException" method to log the JMSException. It would be nice if you can add that log statement for next release.

Even after the patch of moving the "" statement inside the synchronized block, we still encountered deadlock as below:

Name: DefaultMessageListenerContainer-43803
State: BLOCKED on oracle.jms.AQjmsExceptionListener@a77e20 owned by: Thread-92
Total blocked: 1 Total waited: 0

Stack trace:

  • locked oracle.jms.AQjmsConnection@1c15642
  • locked java.lang.Object@91d649
    $Proxy29.start(Unknown Source)

Name: Thread-92
State: BLOCKED on java.lang.Object@91d649 owned by: DefaultMessageListenerContainer-43803
Total blocked: 1 Total waited: 42

Stack trace:

  • locked oracle.jms.AQjmsExceptionListener@a77e20

My suggestion is to make the call to target's start method only if it wasn't already started. The code would like below:

            synchronized (connectionMonitor) {
     if (!started) { //if condition added to avoid possible deadlocks when trying to reset the target connection
              started = true;

Please look into this and let me know what you think of the change and address it accordingly in the next release.

Affects: 2.5.6


Referenced from: commits 6e25ca8, 23a1d07, 83bd56c

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 6, 2009

Rajani Chennamaneni commented

Attaching the patch we used that caused the second set of deadlock traces I mentioned in the description.

Also, My fix suggestion code block didn't render correctly in the description above.

synchronized (connectionMonitor) {
//if condition added to avoid possible deadlocks when trying to reset the target connection
if (!started) {;
started = true;

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 7, 2009

Juergen Hoeller commented

Good point - we can certainly call start just when actually necessary there. I changed this as of 3.0 M4.


Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 8, 2009

Rajani Chennamaneni commented

Thanks Juergen for fixing this so soon :).

Can you also consider adding a log statement in "SingleConnectionFactory.onException" method to log the JMSException it receives. Currently its eating it up making it impossible to see what caused the resetConnection.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: messaging type: bug
None yet

No branches or pull requests

2 participants