[ydzsidemiik]

I tried not closing the sessions explicitly. Still leaks, but the top of the trace has changed:

Explicit session close:

org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.end(Xid, int)
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(XAResource, int)
org.jboss.resource.adapter.jms.JmsSession.close()
com.acme.gateway.util.jms.JmsOperation.execute()

No explicit session close:

org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.end(Xid, int)
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(XAResource, int)
org.jboss.resource.adapter.jms.JmsSessionFactoryImpl.close()
com.acme.gateway.util.jms.JmsOperation.execute()

I didn't see any option to increase the maximum depth of the allocation traces in YourKit, so I tried downloading JProfiler. It too seems to cut off in the same place. I wasn't able to find the option to increase the maximum depth in JProfiler either, do you happen to know where it might be located?

[ydzsidemiik]

Hi Tim,

This issue is causing me serious problems. I am seeing my application sieze up completely for a full minute while the JVM runs a full GC, and even the minor GCs are seriously reducing throughput.

Perhaps if you could help me understand under what circumstances the call chain MessagingXAResource.end -> MessagingXAResource.unsetCurrentTransactionId -> ResourceManager.createLocalTx might be executed, I could take a stab and patching this myself and contribute my findings back to you.

[timfox]

Could you post a simple sample program or test that exhibits the problem and one of the team will take a look?

Thanks.

[ydzsidemiik]

The ejb3mdb example shipped with JBM works to demonstrate the issue. Every time the example is run, the number of ClientTransaction and LocalTx instances in memory goes up by two each. Running a full GC removes one, but the other remains. You can run the example as many times as you want and see the object counts inexorably tick upwards.

[ydzsidemiik]

I should note that I built and deployed the MDB independently of the ant build script, and modified the script to not perform that step itself. The script then simply called the Sender to repeatedly connect to a single deployment of the MDB.

[ataylor]

just to inform, I'm currently investigating this issue and will get back to you as soon as i can.

[ydzsidemiik]

Much appreciated.

[ataylor]

We've investigated this and found the memory leak where you suggested. This is now fixed in the maintenance branch.

This can be patched by checking out and building http://anonsvn.jboss.org/repos/messaging/branches/Branch_Stable

[ydzsidemiik]

Outstanding news. Is there a timeline for the release of SP4 with this fix?

[ataylor]

There are no plans to release an SP4 at this time. The branch Branch_Stable is the maintenance branch which you should use to build against.

[ydzsidemiik]

Fair enough. Should I wait until JBMESSAGING-1221 is closed before building Branch_Stable?

Thanks again to both of you for your time and effort. It is a testament to the quality of JBoss as an organization that you are willing to be responsive even though I am not paying for a support contract.

[ataylor]

yes, that would make sense

[ydzsidemiik]

I applied the fix to SP3 by compiling the 3 changed files from SVN 3601 and replacing the classes in the SP3 jar with the new ones.

It seems to have worked. Cheers!

[mglowacki]

I am using JBoss 5.1.0GA and am having exactly the issue. I checked the jboss-messaging.jar version:

Implementation-Version: 1.4.3.GA (build: CVSTag=JBossMessaging_1_4_3_GA date=200903052203)