March 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by Kevin.Conner＠jboss.com

"mark.little(a)jboss.com" wrote : The current implementation assumes that the AtomicAction instance is around after termination for status, identification and in the event of heuristics potentially for management and recovery information (the log still exists on disk at that point and hence the AA instance can be used to access it). Changing it so that is no longer the case could have implications throughout the areas of the code. I'd prefer to see what is keeping hold of the TransactionImple reference and not releasing that, since it appears that is the root of the leak (assuming we're understanding the reported problem.) No reference to the internal coordinator appears to exist outside of the transactionimpls and their associated transaction manager. The majority of the methods in the base transactionimpl classes assumes that this reference can be nulled, the only unsafe methods appear to be equals(jts) and hashCode (because their results can change) and also get_uid. The subordinate transactionimpls would also have to be change to check for a null coordinator. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028101#4028101 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028101

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by bstansberry＠jboss.com

Here's the reference chain from the classloader back into JBossTS. There's a lot more besides this branching off from the com.arjuna.ats.arjuna.coordinator.TransactionReaper._list ref, but this is the gist of it. I can e-mail someone the full report if it's wanted. | !--org.jboss.mx.loading.UnifiedClassLoader3@1085eba{ url=null ,addedOrder=49} | !--!--ClassLoaderReference @ class $Proxy80 | !--!--!--InstanceOfReference:ToString=ClassloaderLeakStatefulSession:eza31jqw-8 | !--!--!--!--FieldReference UndefinedField@org.jboss.ejb.StatefulSessionEnterpriseContext@13ba312=org.jboss.ejb.StatefulSessionEnterpriseContext(a)13ba312 | !--!--!--!--!--FieldReference private org.jboss.ejb.EnterpriseContext org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor$InstanceSynchronization.ctx=org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor$InstanceSynchronization@122be0b | !--!--!--!--!--!--FieldReference private javax.transaction.Synchronization com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple._theSynch=com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple@ffa9d8 | !--!--!--!--!--!--!--FieldReference private com.arjuna.ats.arjuna.coordinator.SynchronizationRecord com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator._currentRecord=BasicAction: a0b0e66:58c:45f838a3:41 status: ActionStatus.COMMITTED | !--!--!--!--!--!--!--!--FieldReference public com.arjuna.ats.arjuna.coordinator.Reapable com.arjuna.ats.internal.arjuna.coordinator.ReaperElement._control=com.arjuna.ats.internal.arjuna.coordinator.ReaperElement@c47220 | !--!--!--!--!--!--!--!--!--FieldReference private final com.arjuna.ats.internal.arjuna.template.OrderedListElement com.arjuna.ats.internal.arjuna.template.OrderedListEntry._theElement=com.arjuna.ats.internal.arjuna.template.OrderedListEntry@16e2b70 | !--!--!--!--!--!--!--!--!--!--FieldReference private com.arjuna.ats.internal.arjuna.template.OrderedListEntry com.arjuna.ats.internal.arjuna.template.OrderedListEntry._next=com.arjuna.ats.internal.arjuna.template.OrderedListEntry@1e5d007 | !--!--!--!--!--!--!--!--!--!--!--FieldReference private com.arjuna.ats.internal.arjuna.template.OrderedListEntry com.arjuna.ats.internal.arjuna.template.OrderedListEntry._next=com.arjuna.ats.internal.arjuna.template.OrderedListEntry@bc8f01 | !--!--!--!--!--!--!--!--!--!--!--!--FieldReference private com.arjuna.ats.internal.arjuna.template.OrderedListEntry com.arjuna.ats.internal.arjuna.template.OrderedListEntry._next=com.arjuna.ats.internal.arjuna.template.OrderedListEntry@1509443 | !--!--!--!--!--!--!--!--!--!--!--!--!--FieldReference private com.arjuna.ats.internal.arjuna.template.OrderedListEntry com.arjuna.ats.internal.arjuna.template.OrderedList._headOfList=com.arjuna.ats.internal.arjuna.template.OrderedList@1c931fb | !--!--!--!--!--!--!--!--!--!--!--!--!--!--FieldReference private com.arjuna.ats.internal.arjuna.template.OrderedList com.arjuna.ats.arjuna.coordinator.TransactionReaper._list=com.arjuna.ats.arjuna.coordinator.TransactionReaper@126c885 | !--!--!--!--!--!--!--!--!--!--!--!--!--!--!--Root | !--!--!--!--!--!--!--!--!--!--!--!--!--!--!--Reference inside a method - com.arjuna.ats.internal.arjuna.coordinator.ReaperThread::run | !--!--!--!--!--!--!--!--!--!--!--!--!--!--!--FieldReference private com.arjuna.ats.arjuna.coordinator.TransactionReaper com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.reaperObject=Thread[Thread-23,5,jboss] | !--!--!--!--!--!--!--!--!--!--!--!--!--!--!--!--Root | !--!--!--!--!--!--!--!--!--!--!--!--!--!--!--!--Reference inside a method - com.arjuna.ats.internal.arjuna.coordinator.ReaperThread::run All the stuff about Reapable and ReaperThread is what led me to think this wasn't a long-term leak in JBossTS. For more info on the test that produces this, see http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassloaderLeakUnitTestCase View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028097#4028097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028097

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by bstansberry＠jboss.com

"mark.little(a)jboss.com" wrote : "bstansberry(a)jboss.com" wrote : I'm wondering because I wrote some unit tests that check for classloader leaks following an undeployment. If transactions are used, test shows reference chains leading back to JBossTS via a Synchronization. My assumption is JBossTS releases the ref to the Synchronization in some later cleanup task. | | | | What Synchronization? Are you saying that for each transaction, a Synchronization implementation isn't being garbage collected or that other objects from JBossTS aren't being garbage collected? I'm unclear from your description. Using JBossTS; AS Branch_4_2. The specific Synchronization was org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor$InstanceSynchronization (used in EJB2 SFSBs to clear bean locks). I'll remove the state-nulling bit I did and re-run the test. That will produce a report showing the reference chain; I'll post it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028082#4028082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028082

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by mark.little＠jboss.com

The current implementation assumes that the AtomicAction instance is around after termination for status, identification and in the event of heuristics potentially for management and recovery information (the log still exists on disk at that point and hence the AA instance can be used to access it). Changing it so that is no longer the case could have implications throughout the areas of the code. I'd prefer to see what is keeping hold of the TransactionImple reference and not releasing that, since it appears that is the root of the leak (assuming we're understanding the reported problem.) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028070#4028070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028070

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by Kevin.Conner＠jboss.com

We cannot control who has a reference to a transaction as it is exposed to code outside of TS. If there is any code which has a reference to the transaction impl, for whatever reason, then all instances referenced by that transaction cannot be garbaged collected. There is no reason for the transaction impl to keep a reference to the coordinator and associated objects once the transaction has completed. We should disassociate on completion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028056#4028056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028056

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by mark.little＠jboss.com

"Kevin.Conner(a)jboss.com" wrote : "mark.little(a)jboss.com" wrote : The transaction is garbage collected when it completes. | Unless a reference is held elsewhere which is why the transaction should disassociate itself from the coordinator on completion. | If JCA is involved then there was an issue a month or so ago that could have caused a leak, but that's been fixed and was in time for the CR2 build, I believe. The transaction does disassociate itself from the global (VM) repository when it terminates and everything else that has a reference to the transaction is also transient, with the exception of the transaction reaper. However, terminated transactions also remove themselves from there too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028054#4028054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028054

19 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Browser-based configuration editor

by kurt.stam＠jboss.com

Well we could make that listing feature, but i think we could either work off: 1. Deploy as an exploded archive, then look for the jbossesb.xml in META-INF 2. Go into the zip archive and do (1). Note that you can now have more then archive, so the editor may need a drop down box as to which archive you're working on. What do you think? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028051#4028051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028051

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by mark.little＠jboss.com

"bstansberry(a)jboss.com" wrote : I'm wondering because I wrote some unit tests that check for classloader leaks following an undeployment. If transactions are used, test shows reference chains leading back to JBossTS via a Synchronization. My assumption is JBossTS releases the ref to the Synchronization in some later cleanup task. | What Synchronization? Are you saying that for each transaction, a Synchronization implementation isn't being garbage collected or that other objects from JBossTS aren't being garbage collected? I'm unclear from your description. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028049#4028049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028049

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by Kevin.Conner＠jboss.com

"mark.little(a)jboss.com" wrote : The transaction is garbage collected when it completes. Unless a reference is held elsewhere which is why the transaction should disassociate itself from the coordinator on completion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028048#4028048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028048

19 years

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Calling Synchronization.afterCompletion() more than once

by mark.little＠jboss.com

"bstansberry(a)jboss.com" wrote : | I'm wondering because I wrote some unit tests that check for classloader leaks following an undeployment. If transactions are used, test shows reference chains leading back to JBossTS via a Synchronization. My assumption is JBossTS releases the ref to the Synchronization in some later cleanup task. | Are you using the JTA or the JTS implementation from JBossTS? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028047#4028047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028047

19 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2007