June 2012 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1194) TXFramework tests fail intermittently on Java7

by Paul Robinson (JIRA)

11 years, 7 months

2
3
0 / 0

[JBoss JIRA] (JBTM-1181) Add JBOSS Transactional File I/O User Guide TXFileInJava into documentation repo and use jdocbook

by Amos Feng (JIRA)

Amos Feng created JBTM-1181: ------------------------------- Summary: Add JBOSS Transactional File I/O User Guide TXFileInJava into documentation repo and use jdocbook Key: JBTM-1181 URL: https://issues.jboss.org/browse/JBTM-1181 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.0.0.Final there is https://svn.jboss.org/repos/labs/labs/jbosstm/workspace/transactionalFile... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

2
4
0 / 0

[JBoss JIRA] (JBTM-1031) Search for "<String.class> == <String.class>" bugs

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1031: ----------------------------------- Summary: Search for "<String.class> == <String.class>" bugs Key: JBTM-1031 URL: https://issues.jboss.org/browse/JBTM-1031 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Reporter: Paul Robinson Assignee: Amos Feng Priority: Minor Fix For: 5.0.0.M2 A recent bug in XTS recovery was caused by the use of == to compare Strings. String#equals(...) should have been used. We need to search the XTS codebase for other occurrences of this type of bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

2
5
0 / 0

[JBoss JIRA] (JBTM-1137) ArjunaJTS recovery quickstart sometimes throws CORBA.OBJECT_NOT_EXIST exception

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-1137: -------------------------------------- Summary: ArjunaJTS recovery quickstart sometimes throws CORBA.OBJECT_NOT_EXIST exception Key: JBTM-1137 URL: https://issues.jboss.org/browse/JBTM-1137 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 5.0.0.M1 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 6.0.0.Final Running the JTS recovery quickstart (ArjunaJTS/recovery) sometimes, but not always, throws an org.omg.CORBA.OBJECT_NOT_EXIST exception during recovery. When it does happen the relevant XA resoruces still complete but the corresponding log record is left in the ObjectStore and then moved to AssumedComplete on the next pass. When it does happen I notice that there are two threads replaying phase 2, the one that completes removes the servants (for the XA resources) from the ORBs active object map so that when the other thread replays phase 2 the CORBA object no longer exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
1
0 / 0

[JBoss JIRA] (JBTM-1183) XA connections leak in XARecoveryModule

by v a (JIRA)

v a created JBTM-1183: ------------------------- Summary: XA connections leak in XARecoveryModule Key: JBTM-1183 URL: https://issues.jboss.org/browse/JBTM-1183 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.16.4 Environment: JBoss AS 7.1.x, 7.2.0.Alpha1 Reporter: v a Assignee: Tom Jenkinson Priority: Critical XARecoveryModule._xidScans accumulates XA connections if JDBC driver does not implement Connection.isValid(int timeout) method. It's the case for PostgreSQL JDBC driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

6
12
0 / 0

[JBoss JIRA] Created: (JBTM-576) update unit tests

by Jonathan Halliday (JIRA)

update unit tests ----------------- Key: JBTM-576 URL: https://jira.jboss.org/jira/browse/JBTM-576 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.7.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.8.0 There are many unit tests that have lain dormant for some time. Convert them from DTF/junit3 to junit4, wire them to the build and make them pass. This will be done incrementally, one module at a time, following the dependency chain e.g. common, ArjunaCore/arjuna, ArjunaCore/txoj, ... JTA/, .../JTS/... -- 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

11 years, 7 months

4
14
0 / 0

[JBoss JIRA] Created: (JBTM-522) Update UID to support ipv6 and ipv4

by Mark Little (JIRA)

Update UID to support ipv6 and ipv4 ----------------------------------- Key: JBTM-522 URL: https://jira.jboss.org/jira/browse/JBTM-522 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Affects Versions: 4.6.0 Reporter: Mark Little Assignee: Mark Little Fix For: 5.0.0 It's possible to have a version that supports both v4 and v6. -- 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

11 years, 7 months

5
14
0 / 0

[JBoss JIRA] (JBTM-1157) Assign NodeID automatically

by Clebert Suconic (JIRA)

Clebert Suconic created JBTM-1157: ------------------------------------- Summary: Assign NodeID automatically Key: JBTM-1157 URL: https://issues.jboss.org/browse/JBTM-1157 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Clebert Suconic Assignee: Tom Jenkinson It shouldn't be needed to assign the node-id manually IMO. You could store the node-id on a file and recover it for subsequent starts. On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file. In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

2
9
0 / 0

[JBoss JIRA] (JBTM-1187) Review TXFramework Quickstarts

by Paul Robinson (JIRA)

11 years, 10 months

2
13
0 / 0

[JBoss JIRA] Created: (JBTM-764) ConnectionImple/RecoverableConnection leak in ConnectionManager because of the pooling

by Mauro Molinari (JIRA)

ConnectionImple/RecoverableConnection leak in ConnectionManager because of the pooling -------------------------------------------------------------------------------------- Key: JBTM-764 URL: https://jira.jboss.org/browse/JBTM-764 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Affects Versions: 4.6.1 Environment: JBossTS JTA embedded in a webapp with Spring Reporter: Mauro Molinari Priority: Critical This is indirectly related to JBTM-529. Suppose you are using JBossTS JTA within your webapp, configured using Spring and using the DynamicClass mechanism to get connections. Suppose you're doing connection pooling under JBossTS: that is, the DynamicClass implementation is pooling XA connections from the actual XADataSource provided by the DBMS JDBC driver. This is a different approach from the one described in JBTM-529 and we switched to this one because of the problems encountered with JBTM-529, thinking that it could be a more correct approach. In this scenario, the client application code is doing the following: - start a transaction - request a new JDBC connection: this can be done either by using the DriverManager or by using Spring SimpleDriverDataSource; JBossTS JTA TransactionalDriver actually creates a new ConnectionImple, which asks the DynamicClass implementation to get a new XAConnection and gets a physical JDBC connection from that XAConnection; because of the XAConnection pooling provided by the DynamicClass implementation, this XAConnection might be a new one or a reused one, but I think this is not relevant to the problem - do what you have to do with the connection - close the connection: this causes the invocation of ConnectionImple.close - do other things within the transaction - commit the transaction Now, what I see is this: com.arjuna.ats.internal.jdbc.ConnectionImple.close() does the following check: if (!_recoveryConnection.inuse()) { ConnectionManager.remove(this); // finalize? } The problem is that since the transaction is still active, _recoveryConnection.inuse() returns true, because it checks for the XAResource associated with it: in the case of DirectRecoverableConnection, this is done when com.arjuna.ats.internal.jdbc.DirectRecoverableConnection.reset() is invoked, that is when the RecoverableConnection is closed, and so when the transaction terminates. The ultimate effect is that the ConnectionImple is never removed from the caching map of ConnectionManager, because it should have been when the connection was closed, BUT at that time it was not because its RecoverableConnection was in use. What we're actually seeing in our application is that com.arjuna.ats.internal.jdbc.ConnectionManager._connections grows indefinitely. This causes a memory leak and severe performance problems, also because the test for cache hits in ConnectionManager is made using a linear iteration over the map (this could be improved a lot). The workaround is to disable connection pooling within the transaction by using the patch from JBTM-529 (but also please see my last comment, too!). To fix the problem I think that some approaches could be followed: - the easiest one is to remove the old connections without any associated transaction when iterating over _connections: that is, if I'm checking a connection conn which has tx1 == null, I could remove conn from _connections; in this way I'm sure that sooner or later a ConnectionImple, which hasn't been removed from that map previously, will be when another connection is requested - implement com.arjuna.ats.internal.jdbc.ConnectionImple.equals(Object) and hashCode() so that the call to _connections.put(conn, conn) will "replace any old (closed) connection which had the same connection information", as the inline documentation says; this is not true right now, because equality is based on identity; this might be the less invasive solution, but I don't know how easy it would be to do and if there may be regressions in other areas - provide a mechanism to invoke com.arjuna.ats.internal.jdbc.ConnectionManager.remove(ConnectionImple) for all the ConnectionImple objects bound to a transaction when this is completed (committed or rolled back) In any case, a smarter use of _connections would be useful for performance (using a Transaction=>ConnectionImple mapping, for instance...). I would also consider the complete removal of in-transaction connection pooling: after all, every production use of JBossTS JTA will certainly use some sort of connection pooling by its own, so the benefits of using another level of pooling could be negligible. Even worse, performance could be compromised if the search for the hit in the pool is not efficient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues June 2012