January 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-468) make RecoveryManager restartable

by Jonathan Halliday (JIRA)

make RecoveryManager restartable -------------------------------- Key: JBTM-468 URL: https://jira.jboss.org/jira/browse/JBTM-468 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Application Server Integration, Recovery Affects Versions: 4.5 Reporter: Jonathan Halliday Fix For: 4.6 Stopping and restarting the transaction manager inside JBossAS causes problems, because the recovery system does not like to be restarted once it is stopped: java.lang.IllegalThreadStateException at java.lang.Thread.start(Thread.java:571) at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.start(RecoveryManagerImple.java:236) at com.arjuna.ats.arjuna.recovery.RecoveryManager.startRecoveryManagerThread(RecoveryManager.java:226) at com.arjuna.ats.jbossatx.jts.TransactionManagerService.start(TransactionManagerService.java:285) Options would seem to be disposing the static singleton _recoveryManager in RecoveryManager and recreating it on the next start, effectively causing a new RecoveryManagerImple to be instantiated, or keep the RecoveryManagerImple instance and rework its impl so that the PeriodicRecovery _periodicRecovery is disposed and recreated on restart. Either one has slightly odd semantics as the PeriodicRecovery is a Thread (which can't be restarted so has to be replaced) and also the object that has the module list and the server socket, so disposal and/or recreation of this state will be needed on restart. Maybe better to rename stop() to dispose() or something similarly final, to indicate the semantics are 'throw this away and start again' rather than giving the impression that stop/start == suspend/resume which is misleading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

3
8
0 / 0

[JBoss JIRA] Created: (JBTM-405) PropertyManagerImpl.getPropertyFromSubTree(String name) looks for properties in _parentPropertyManagers and not in _childPropertyManagers

by Dmitri Voronov (JIRA)

PropertyManagerImpl.getPropertyFromSubTree(String name) looks for properties in _parentPropertyManagers and not in _childPropertyManagers ----------------------------------------------------------------------------------------------------------------------------------------- Key: JBTM-405 URL: https://jira.jboss.org/jira/browse/JBTM-405 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.3.0.GA Environment: JBoss-4.2.3.GA Reporter: Dmitri Voronov PropertyManagerImpl.getPropertyFromSubTree(String name) looks for properties in _parentPropertyManagers and not in _childPropertyManagers So the call: String tsmPortStr = arjPropertyManager.propertyManager.getProperty("com.arjuna.ats.arjuna.recovery.transactionStatusManagerPort" ) ; from com.arjuna.ats.arjuna.recovery.TransactionStatusManager misses, whereby the property exists in a child property manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

3
6
0 / 0

[JBoss JIRA] Created: (JBTM-480) add release packaging script

by Jonathan Halliday (JIRA)

add release packaging script ---------------------------- Key: JBTM-480 URL: https://jira.jboss.org/jira/browse/JBTM-480 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Release Process Affects Versions: 4.5 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6 The handy ant script that builds and packages JBossTS releases is currently squirrelled away on my laptop. This is a Bad Thing. Drag it kicking and screaming into the repository so it can't escape. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-420) add in-memory (i.e. Volatile) ObjectStore impl.

by Jonathan Halliday (JIRA)

add in-memory (i.e. Volatile) ObjectStore impl. ----------------------------------------------- Key: JBTM-420 URL: https://jira.jboss.org/jira/browse/JBTM-420 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Testing, Transaction Core Affects Versions: 4.4.0.GA Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.5 For performance testing purposes it would be nice to have a pure in-memory objectstore implementation. This would store object states in the JVM's RAM and thus facilitate comparisons: - comparing driving XAResources directly from the application code vs. via JBossTS would give the overhead of the transaction manager code without any i/o overhead i.e. tell us how performant the transaction manager's 'business logic' is and what the maximum theoretical throughput is if the persistent storage is not a bottleneck. Could also be useful when stress testing or profiling the rest of the transaction manager code. - comparing against any other ObjectStore provides figures that show exactly what performance impact that store has i.e. it provides a baseline for evaluating other stores. Previously it's only been possible to compare any given store impl against driving XA resources directly, which does not account for the overhead of the transaction manager code. Naturally there's no crash recovery support, so it's totally unsuitable for production usage. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-483) AppServerJDBCXARecovery should not use java 1.5 syntax

by Jonathan Halliday (JIRA)

AppServerJDBCXARecovery should not use java 1.5 syntax ------------------------------------------------------ Key: JBTM-483 URL: https://jira.jboss.org/jira/browse/JBTM-483 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration Affects Versions: 4.2.3.CP03, 4.2.3.SP8 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.2.3.SP8, 4.2.3.CP04 Ensure the class compiles with java 1.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-448) Split XTS code into an API jar and an implementation jar

by Andrew Dinn (JIRA)

Split XTS code into an API jar and an implementation jar -------------------------------------------------------- Key: JBTM-448 URL: https://jira.jboss.org/jira/browse/JBTM-448 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.4.0.GA Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.6 This will make it clearer which classes are intended for use by XTS clients. The API jar can be installed in the JBoss AS client directory for clients to link against. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
1
0 / 0

[JBoss JIRA] Commented: (JBTM-66) "Already marked for rollback" Exception could include original cause

by Jonathan Halliday (JIRA)

[ https://jira.jboss.org/jira/browse/JBTM-66?page=com.atlassian.jira.plugin... ] Jonathan Halliday commented on JBTM-66: --------------------------------------- An intermediate solution that does not require changes to the public API is to cache a stacktrace at the point setRollbackOnly() is called and attach it as the cause when a RollbackException is thrown. This is similar to the technique the JBossAS CachedConnectionManager uses. setRollbackOnly() { ... rollbackReason = new Throwable("STACKTRACE"); } It still would not provide the original reason, but it would at least narrow down where to look for it. I'm slightly concerned about the performance hit, but that's probably premature optimization. > "Already marked for rollback" Exception could include original cause > -------------------------------------------------------------------- > > Key: JBTM-66 > URL: https://jira.jboss.org/jira/browse/JBTM-66 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA Implementation > Affects Versions: 4.2 > Environment: JBoss 4.0.4.CR2 > Reporter: Richard Kennard > Assignee: Jonathan Halliday > Priority: Optional > Fix For: 4.6 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > First up, thank you for providing such a wondefully stable implementation! I have a small feature request: > At present whenever a, say, SFSB throws a RuntimeException, JTA goes into 'rollback' mode. From then on, anyone who tries to do any further work (including when the SessionContext tries to remove the rolled back SFSB) will trigger a different RuntimeException saying, in short, 'Already marked for rollback'. > It would be very helpful if the 'Already marked for rollback' Exception could include, as its getCause (which is standard as of JDK 1.4), the original exception that started off the rollback? At present we are often left with the situation where all the original caller gets back is a 'Already marked for rollback' Exception, and there is no way to 'drill down' to find what the original cause was. > Of course, you could also argue that the SessionContext should be smarter about trying to remove rolled back EJBs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-469) TransactionManagerService does not unbind JNDI refs on undeploy

by Jonathan Halliday (JIRA)

TransactionManagerService does not unbind JNDI refs on undeploy --------------------------------------------------------------- Key: JBTM-469 URL: https://jira.jboss.org/jira/browse/JBTM-469 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration Affects Versions: 4.5 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6 per discussion at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144514, the TransactionManagerService should unbind any JNDI names it is responsible for when it gets undeployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-467) improve JTS XAResource.commit error handling

by Jonathan Halliday (JIRA)

improve JTS XAResource.commit error handling -------------------------------------------- Key: JBTM-467 URL: https://jira.jboss.org/jira/browse/JBTM-467 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Implementation Affects Versions: 4.5 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6 The JTS version of XAResourceRecord commit() currently fails to treat XAER_NOTA and XAER_PROTO as errors. This is insufficiently paranoid. These error codes should result in either a heuristic or a rollback. The XA spec is sufficiently ambiguous that deciding which is really a matter of choosing how far to take the 'presumed abort' philosophy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBTM-403) Check OTS TransactionFactory is exported through app server

by Mark Little (JIRA)

Check OTS TransactionFactory is exported through app server ----------------------------------------------------------- Key: JBTM-403 URL: https://jira.jboss.org/jira/browse/JBTM-403 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Implementation Reporter: Mark Little Assignee: Mark Little -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 1 month

2
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2009