January 2011 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-820) Update docs with new modularity structure

by Mark Little (JIRA)

Update docs with new modularity structure ----------------------------------------- Key: JBTM-820 URL: https://issues.jboss.org/browse/JBTM-820 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation Reporter: Mark Little Assignee: Mark Little Fix For: 4.15.0 Now that we have moved to docbook it should be possible to reapply the restructuring to the docs that was started when they were still OpenOffice. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBTM-748) Calling rollback_only via OTS is throwing the wrong exception

by Michael Musgrove (JIRA)

Calling rollback_only via OTS is throwing the wrong exception ------------------------------------------------------------- Key: JBTM-748 URL: https://jira.jboss.org/browse/JBTM-748 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Affects Versions: 4.11.0 Reporter: Michael Musgrove Assignee: Andrew Dinn Fix For: 4.12.0 Occasionally our BlackTie CI test run is failing when marking a transaction rollback only because it is getting the wrong exception back from the transaction manager 16:11:10,296 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_18] - TransactionReaper::check timeout for TX -53ee7cfb:10e2:4c0fa834:22ec in state RUN [exec] 2010-06-09 16:11:10,296 [0x0000123c] WARN (TxLogControl :153 ) - rollback_only: INVALID_TRANSACTION minor: 20001 16:11:10,328 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_7] - TransactionReaper::doCancellations worker Thread[Thread-18,5,jboss] successfully canceled TX -53ee7cfb:10e2:4c0fa834:22ec The second log message comes from the C client (the other two from the reaper). The CORBA System exception major/minor code represents INVALID_TRANSACTION/INACTIVE_TRANSACTION which according to the OTS spec is incorrect. A look at the code shows a race condition between a BlackTie C client marking a transaction abort only and the Transaction Reaper cancelling it (due to a timeout being reached). The reaper eventually winds up in ControlImple.destroy() where the CORBA object representing the transaction is destroyed. There is a window where the C client request reaches JacORB just before the reaper has had a chance to destroy the CORBA object resulting in the wrong exception being returned. -- 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

13 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (JBTM-619) Cannot enlist two Oracle XAConnection resources in one transaction

by Wade Poziombka (JIRA)

Cannot enlist two Oracle XAConnection resources in one transaction ------------------------------------------------------------------ Key: JBTM-619 URL: https://jira.jboss.org/jira/browse/JBTM-619 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Affects Versions: 4.7.0 Environment: Windows and Linux. Reporter: Wade Poziombka An attempt to enlist two Oracle connections causes the second enlistResource to fail with an exception similar to: oracle.jdbc.xa.OracleXAException at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:938) at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:244) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:902) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:513) Note the line number changes a bit depending on version of Oracle JDBC etc. However, the affect is always the same. There are others who noted this problem on the forum with no resolution or reply (except my own concurring with the observation). In particular two connections to same server using different user id's and passwords. I will test whether two completely separate oracle instances have this issue and update the bug. -- 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

13 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-443) check LastResource logging and recovery

by Jonathan Halliday (JIRA)

check LastResource logging and recovery --------------------------------------- Key: JBTM-443 URL: https://jira.jboss.org/jira/browse/JBTM-443 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation, Recovery Affects Versions: 4.4.0.GA Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6 Where transactions contain LastResource, they may not be fully recoverable. Check if LastResource records are written to the log and if so, what happens to them during recovery. Optimise the case where a tx contains multiple last resources, as we need to write a log for such a tx only if it also contains real resources. The case where the tx only has a single resource enlisted is irrelevant as the onePhaseCommit optimization already skips logging. -- 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

13 years, 8 months

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-774) TM is not fully OTS spec compliant with respect to XA

by Michael Musgrove (JIRA)

TM is not fully OTS spec compliant with respect to XA ------------------------------------------------------ Key: JBTM-774 URL: https://jira.jboss.org/browse/JBTM-774 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Affects Versions: 4.6.1.CP07, 4.12.0 Reporter: Michael Musgrove Assignee: Mark Little Fix For: 4.13.0, 4.6.1.CP08 According to the OTS specification the Propagation Context should always be available. Annex B2.2 says: "The Transaction Service does not restrict the availability of the PropagationContext: the operation get_txcontext on the Coordinator never raises Unavailable." However the TM is raising this exception if the transaction has been aborted (for example if the reaper has detected that the transaction has timed out). [The method ArjunaTransactionImple.get_txcontext will always raise CosTransactions.Unavailable if the transaction is not active.] This problem was observed whilst running the BlackTie test suite. -- 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

13 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBTM-821) Cope With Zero Length Transaction Log Files

by James Wilson (JIRA)

Cope With Zero Length Transaction Log Files ------------------------------------------- Key: JBTM-821 URL: https://issues.jboss.org/browse/JBTM-821 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.6.1.CP07 Reporter: James Wilson Fix For: 4.6.1.CP09 In certain situations, zero-length transactions log files can be created. When this happens there are repeated warning messages in the logs. Can these be dealt with another way and/or possibly ignored? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
7
0 / 0

[JBoss JIRA] Created: (JBTM-824) suppress orb sutdown warning

by Jonathan Halliday (JIRA)

suppress orb sutdown warning ---------------------------- Key: JBTM-824 URL: https://issues.jboss.org/browse/JBTM-824 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Affects Versions: 4.14.0, 4.6.1.CP08 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.15.0, 4.6.1.CP09 When running on an ORB that is shut down in another thread, the ORBRunner thread exit will whine: WARN [com.arjuna.orbportability.logging.loggerI18N] (Thread-19) [com.arjuna.orbportability.OA.caughtexception] shutdownObject caught: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed at com.arjuna.orbportability.RootOA.shutdownObject(RootOA.java:288) at com.arjuna.ats.internal.jts.OTSImpleManager.purge(OTSImpleManager.java:187) at com.arjuna.ats.internal.jts.lifecycle.ShutdownOTS.work(ShutdownOTS.java:73) at com.arjuna.orbportability.RootOA.destroy(RootOA.java:87) at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.ORBRunner.run(ORBRunner.java:79) We don't detect ORB shutdown internally, so do the cleanup unconditionally rather than only if the ORB is still running. Some resulting errors are already silently ignored. This one should be too - it's easier than adding lifecycle tracking to the orb portability layer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-818) Order in which JBoss nodes are restarted affects the outcome of XA transactions recovery

by Tom Ross (JIRA)

Order in which JBoss nodes are restarted affects the outcome of XA transactions recovery ----------------------------------------------------------------------------------------- Key: JBTM-818 URL: https://jira.jboss.org/browse/JBTM-818 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Affects Versions: 4.6.1.CP07 Environment: JBoss 5.1 EAP Postgres 8.4 Reporter: Tom Ross The test case consisting of a servlet and two stateless session beans. The servlet and SLSB A are deployed on node A and SLSB B is deployed on node B. The servlet calls SLSB A on node A. The bean then retrieves XA data source from JNDI, creates JDBC connection and inserts a row into a table in the database (Postgres). Next it retrieves JmsXa connection factory from JNDI, creates connection and sends a message to a queue. After that it calls SLSB B on node B that retrieves XA data source from JNDI, creates JDBC connection and inserts a row into a table in the database. At the end it should produce two rows in the database table and a message on the queue. Node A has a simple byteman rule that kills node A JVM at the end of BasicAction.prepare() method. After JVM on node A dies, the JVM on node B gets "kill -9". The above test case produces two different results that depend on the order in which JBoss nodes are restarted. If node is restarted A first followed by node B the outcome is consistent result i.e. two rows can be seen in the database. If the node B is restarted first followed by node A the outcome is inconsistent i.e. only one row in the table; row inserted by SLSB A on node A. Both beans use the default attributes for transaction support and both nodes have been configured to use JTS transactions. During recovery node B reports the following error: 2010-11-22 10:25:37,916 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] (Thread-22) PeriodicRecovery: background thread backing off 2010-11-22 10:25:37,922 WARN [com.arjuna.ats.jta.logging.loggerI18N] (RequestProcessor-2) [com.arjuna.ats.internal.jta.resources.jts.orbspecific.xaerror] [com.arjuna.ats.internal.jta.resources.jts.orbspecific.xaerror] XAResourceRecord.rollback caused an XA error: XAException.XAER_RMERR 2010-11-22 10:25:37,922 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] (RequestProcessor-2) OutputObjectState::OutputObjectState() Where as node A reports 2010-11-22 10:28:15,174 WARN [com.arjuna.ats.jts.logging.loggerI18N] (Thread-22) [com.arjuna.ats.internal.jts.resources.rrcaught] ResourceRecord commit - caught exception: org.omg.CORBA.OBJECT_NOT_EXIST: Server-side Exception: unknown oid vmcid: 0x0 minor code: 0 completed: No Postgres log contains the following error: 2010-11-22 10:25:37 GMTERROR: prepared transaction with identifier "131072_Mi0tM2Y1N2ZlOWM6YzQ5ZTo0Y2VhNDM4MDpmYQ==_LTNmNTdmZTkyOjRhZDY6NGNlYTQzOGQ6ZmQ=" does not exist 2010-11-22 10:25:37 GMTSTATEMENT: ROLLBACK PREPARED '131072_Mi0tM2Y1N2ZlOWM6YzQ5ZTo0Y2VhNDM4MDpmYQ==_LTNmNTdmZTkyOjRhZDY6NGNlYTQzOGQ6ZmQ=' -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
8
0 / 0

[JBoss JIRA] Created: (JBTM-823) Xid recovery scans assume same list ordering

by Jonathan Halliday (JIRA)

Xid recovery scans assume same list ordering -------------------------------------------- Key: JBTM-823 URL: https://issues.jboss.org/browse/JBTM-823 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.14.0, 4.6.1.CP08 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.15.0, 4.6.1.CP09 For RM driven recovery, two consecutive recovery scans are performed with a delay between. Only Xids appearing in both are eligible for recovery. This prevents momentarily prepared, normally executing branches from being incorrectly aborted. RecoveryXids.toRecover incorrectly compares the content of the two lists, leading to some Xids not being recovered in a timely manner if the list content or order partially changes between scans. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-822) Cope With Zero Length Transaction Log Files

by James Wilson (JIRA)

Cope With Zero Length Transaction Log Files ------------------------------------------- Key: JBTM-822 URL: https://issues.jboss.org/browse/JBTM-822 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.6.1.CP07 Reporter: James Wilson Assignee: Jonathan Halliday Fix For: 4.6.1.CP09 In certain situations, zero-length transactions log files can be created. When this happens there are repeated warning messages in the logs. Can these be dealt with another way and/or possibly ignored? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2011