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

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

by mark.little＠jboss.com

http://jira.jboss.com/jira/browse/JBTM-205 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028168#4028168 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028168

19 years

1
0
0 / 0

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

by mark.little＠jboss.com

OK, I believe I have found the problem. TransactionImple terminates the transaction via the TwoPhaseCoordinator methods end and cancel. These do not affect the TransactionReaper: only the AtomicAction methods commit and abort do that. Hence the transaction remains referenced by the reaper until the timeout goes off, at which point the reaper will discard it silently. So on the good side, the leak only exists for the duration of the original timeout. On the bad side, there's a leak. I'll take a look at this tomorrow to see how we fix it. It's not as simple as terminating via AA versus TPC. Caveat: I'm looking at the JBossTS 4.1 codebase, but I suspect this is the same. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028166#4028166 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028166

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 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. | I'm not happy to make such a change in code that has worked successfully for a long time unless it's strictly necessary: so far I'm not convinced it is. AtomicAction is exposed outside of the implementation allowing for recovery hooks with 3rd parties (see previous entry). Changing that behaviour can have significant knock on effects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028160#4028160 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028160

19 years

1
0
0 / 0

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

by kurt.stam＠jboss.com

Yes is it, but we're working to convert over the first quickstart (working through the issues). Hopefully by tonight this first one will be done, the others should follow tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028147#4028147 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028147

19 years

1
0
0 / 0

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

by derek.adams

I think that's a good idea. The 'reload configuration' button in the server tab would end up being a dropdown with the list of *.esb dirs and zips. The upload and download servlets would have a parameter indicating which esb archive is being read/written. Is the support for esb archives already in the codebase? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028145#4028145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028145

19 years

1
0
0 / 0

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

by Kevin.Conner＠jboss.com

I'm downloading 4.2 now and will try to reproduce it this evening. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028125#4028125 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028125

19 years

1
0
0 / 0

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

by bstansberry＠jboss.com

Also, I can eliminate the classloader leak by clearing state in the synchronization's afterCompletion(), so that tells me afterCompletion() is being invoked; i.e. it's not a case of a tx not being committed/rolled back. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028122#4028122 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028122

19 years

1
0
0 / 0

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

by bstansberry＠jboss.com

"Kevin.Conner(a)jboss.com"At which point was this reference graph produced?[/quote wrote : | | The test makes several independent calls on CMT session beans with default semantics, so for each call the tx should be committed on method exit. | | The test then undeploys the deployment. | | The graph is produced after the undeployment. Before it's produced numerous attempts to force release of a WeakReference to the classloader are made, so it's probably a good 15-20 seconds after the undeploy completes before the heap snapshot is taken. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028118#4028118 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028118

19 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AspectFactory and classloading

by clebert.suconic＠jboss.com

I tested using this method Ovidiu mentioned and it worked.. my scoping problem was fixed after using this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028116#4028116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028116

19 years

1
0
0 / 0

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

by Kevin.Conner＠jboss.com

"bstansberry(a)jboss.com" wrote : All the stuff about Reapable and ReaperThread is what led me to think this wasn't a long-term leak in JBossTS. The coorindator should have been removed from the TransactionReaper when commit/abort were called. At which point was this reference graph produced? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028109#4028109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4028109

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