[
http://jira.jboss.com/jira/browse/JBCACHE-1326?page=all ]
Brian Stansberry closed JBCACHE-1326.
-------------------------------------
Fix Version/s: (was: 2.2.0.GA)
Resolution: Done
TxInterceptor leaks MethodCall to thread
----------------------------------------
Key: JBCACHE-1326
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1326
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transactions
Affects Versions: 2.1.0.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.1.1.GA
The various Synchronization callbacks in TxInterceptor end up calling the equivalent of
cache.getInvocationContext().setMethodCall(xxx) but then don't restore the
InvocationContext to its previous state when done. All other calls to
InvocationContext.setMethodCall() do reverse themselves after the call is executed, so the
effect is whatever MethodCall a TxInterceptor synchronization last associated to a thread
ends up staying with that thread until some random other synchronization changes it to
something different.
This is showing up in the AS as a classloader leak, since the leaked MethodCall has a ref
to undeployed classes. If a server had a large thread pool, the leak could be long
lasting.
I've added an assertion to
org.jboss.cache.invocationcontext.TransactionTest.doScrubbingTest that shows the problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira