December 2008 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-444) Slow memory leak in BaseTransaction

by Andrew McDowell (JIRA)

Slow memory leak in BaseTransaction ----------------------------------- Key: JBTM-444 URL: https://jira.jboss.org/jira/browse/JBTM-444 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP7 Environment: Windows XP and Solaris, Java 1.5.0_14 Reporter: Andrew McDowell We had JBossAS running for approximately 4 weeks under extremely heavy load, and reached an OutOfMemory condition. Heap Dump analysis showed that the class com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction dominated 85% of the heap space. In the class com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction, there is a private Hashtable _timeouts, into which a thread id and a timeout value are placed when transactions are started. However, the entries in the hashtable are never removed, even if the thread dies. Given all the JBossAS invokers for EJBs create/destroy worker threads, it means that client transactions can leak approximately 600 bytes (the String, Integer and Hashtable$Entry). The _timeouts table in the heap dump had some 6 million entries and a retained heap size of over 1Gb. Our workaround to the problem is that we are actively monitoring heap size and performing rolling restarts when the heap space is too low. You may want to consider using a ThreadLocal to store the timeout instead of a Hashtable, which would accomplish the goal of storing the timeout value per thread, but would be collected if the Thread died, but I will leave implementation speculation to you unless I find the time to submit a patch. -- 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, 9 months

5
13
0 / 0

[JBoss JIRA] Created: (JBTM-397) Pull higher-performance transaction log implementation across from backup

by Mark Little (JIRA)

Pull higher-performance transaction log implementation across from backup ------------------------------------------------------------------------- Key: JBTM-397 URL: https://jira.jboss.org/jira/browse/JBTM-397 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.6 -- 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, 9 months

1
4
0 / 0

[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, 10 months

3
3
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, 10 months

5
14
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, 10 months

3
6
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, 10 months

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

15 years, 10 months

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

15 years, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (JBTM-442) AppServerJDBCXARecovery fails if datasource not yet deployed

by Jonathan Halliday (JIRA)

AppServerJDBCXARecovery fails if datasource not yet deployed ------------------------------------------------------------ Key: JBTM-442 URL: https://jira.jboss.org/jira/browse/JBTM-442 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration Affects Versions: 4.2.3.CP02, 4.2.3.SP7 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.2.3.SP8, 4.2.3.CP03 At As startup, the transaction manager may deploy before the datasources. If a recovery pass occurs before the datasource is deployed, Bad Things will happen. Either delay the first recovery pass at startup, or make the AppServerJDBCXARecovery rebust against this. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-441) AppServerJDBCXARecovery does not cope with stale connections

by Jonathan Halliday (JIRA)

AppServerJDBCXARecovery does not cope with stale connections ------------------------------------------------------------ Key: JBTM-441 URL: https://jira.jboss.org/jira/browse/JBTM-441 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration Affects Versions: 4.2.3.CP02, 4.2.3.SP7 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.2.3.SP8, 4.2.3.CP03 If the db bounces whilst the app server stays up, the AppServerJDBCXARecovery is left holding an invalid connection, which causes XAResource on it to throw spurious errors. It should refresh the connection on every call, or at least check it for validity before handing out an XAResource based on it. -- 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, 11 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues December 2008