February 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-347) Make sure XTS works with HTTPS

by Mark Little (JIRA)

Make sure XTS works with HTTPS ------------------------------ Key: JBTM-347 URL: http://jira.jboss.com/jira/browse/JBTM-347 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: WS-T Implementation Reporter: Mark Little Assigned To: Andrew Dinn Priority: Critical Fix For: 4.4 WS-TX 1.1 recommended (though did not mandate) HTTPS for the "transport". For interoperability, HTTPS cannot be mandated, but some implementations (e.g., MSFT) don't have an "off switch" and won't work unless HTTPS is used. Yes, this breaks interoperability, but it's unlikely to change. We need to make sure that we can work successfully with HTTPS and MSFT. -- 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

15 years, 2 months

3
3
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: --------------------------------------- Done, with the slight caveat that the data is local to the TransactionImple so it won't work between JVMs in the JTS ie. you get the trace of who called setRollbackOnly only if the caller was in the same JVM as the commit() is called. Probably good enough for now. > "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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (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 closed JBTM-66. --------------------------------- Resolution: Done > "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

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-369) String property replacement in configuration

by Dmitri Voronov (JIRA)

String property replacement in configuration -------------------------------------------- Key: JBTM-369 URL: http://jira.jboss.com/jira/browse/JBTM-369 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.3.0.GA Reporter: Dmitri Voronov Please implement string property replacement in jbossjta-properties.xml like: <property name="com.arjuna.ats.arjuna.xa.nodeIdentifier" value="${my.unique.name}"/> -- 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

15 years, 2 months

5
14
0 / 0

[JBoss JIRA] Created: (JBTM-482) rename properties file

by Jonathan Halliday (JIRA)

rename properties file ---------------------- Key: JBTM-482 URL: https://jira.jboss.org/jira/browse/JBTM-482 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.5 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6 To facilitate the integration of JTA and JTS with JBossAS, both flavours of JBossTS should use jbossts-properties.xml rather than having differently named properties files. -- 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

15 years, 2 months

1
1
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

15 years, 2 months

3
6
0 / 0

[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

15 years, 2 months

3
8
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

15 years, 2 months

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

15 years, 2 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2009