[jbossts-issues] [JBoss JIRA] Work started: (JBTM-818) Order in which JBoss nodes are restarted affects the outcome of XA transactions recovery
Mark Little (JIRA)
jira-events at lists.jboss.org
Sun Dec 19 13:45:18 EST 2010
[ https://issues.jboss.org/browse/JBTM-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on JBTM-818 started by Mark Little.
> Order in which JBoss nodes are restarted affects the outcome of XA transactions recovery
> Key: JBTM-818
> URL: https://issues.jboss.org/browse/JBTM-818
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS
> Affects Versions: 4.13.0, 4.6.1.CP07
> Environment: JBoss 5.1 EAP Postgres 8.4
> Reporter: Tom Ross
> Assignee: Mark Little
> Fix For: 4.15.0, 4.6.1.CP09
> Attachments: testCase.zip
> 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
More information about the jbossts-issues