11:18 a.m.
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.2.3, 4.4
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with the
distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID, and
the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
11:24 a.m.
New subject: [JBoss JIRA] Updated: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=all ]
Mark Little updated JBTM-187:
-----------------------------
Fix Version/s: (was: 4.2.3)
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.4
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
11:46 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=comments#action_12350452 ]
Mark Little commented on JBTM-187:
----------------------------------
At first glance this looks like you're getting back the local transaction id during
recovery rather than the imported name.
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.4
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
11:55 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=comments#action_12350457 ]
Mark Little commented on JBTM-187:
----------------------------------
After an unsuccessful run, if you look in the object store, what do you see?
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.4
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
2:33 p.m.
New subject: [JBoss JIRA] Updated: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=all ]
Stephen Burdeau updated JBTM-187:
---------------------------------
Attachment: PutObjectStoreDirHere.zip
Mark,
I just reran the test. In this case:
DTPRA called XATerminator.prepare and XATerminator.commit with the following XID:
0x44545031,
0xa08006092b81403f8176768f52000082040077a101,
0x06092b81403f815561ae73
After restart, the XID returned from XATerminator.recover is the following:
131075,
'1--3fc02a9f:e68:45a532ca:7d'
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
The attached file is the entire zipped object store before JBoss was restarted to attempt
recovery.
Does this tell you what you want to know?
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.4
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
2:41 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=comments#action_12350518 ]
Mark Little commented on JBTM-187:
----------------------------------
I think so. We just need to create a simple stand-alone example to duplicate your
problem.
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.4
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
2:41 a.m.
New subject: [JBoss JIRA] Assigned: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=all ]
Mark Little reassigned JBTM-187:
--------------------------------
Assignee: Jonathan Halliday (was: Mark Little)
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Jonathan Halliday
Fix For: 4.4
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
2:45 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=comments#action_12350520 ]
Mark Little commented on JBTM-187:
----------------------------------
To save time and increase the chance any fix can get into 4.2.3, do you have a stand-alone
example we could use?
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Jonathan Halliday
Fix For: 4.4
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
1:35 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=comments#action_12350584 ]
Stephen Burdeau commented on JBTM-187:
--------------------------------------
I think I have a self contained test, but the zip file is large. Is there somewhere I can
upload a large file? (90MB)?
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Jonathan Halliday
Fix For: 4.4
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
4:49 p.m.
New subject: [JBoss JIRA] Assigned: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=all ]
Mark Little reassigned JBTM-187:
--------------------------------
Assignee: Mark Little (was: Jonathan Halliday)
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.2.3
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
4:49 p.m.
New subject: [JBoss JIRA] Updated: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=all ]
Mark Little updated JBTM-187:
-----------------------------
Fix Version/s: 4.2.3
(was: 4.4)
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.2.3
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
4:52 p.m.
New subject: [JBoss JIRA] Closed: (JBTM-187) Problem recovering inbound transaction
[ http://jira.jboss.com/jira/browse/JBTM-187?page=all ]
Mark Little closed JBTM-187.
----------------------------
Resolution: Done
Fixed and the stand-alone test provided passes as far as we can tell.
Problem recovering inbound transaction
--------------------------------------
Key: JBTM-187
URL: http://jira.jboss.com/jira/browse/JBTM-187
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.2.2
Reporter: Peter Johnson
Assigned To: Mark Little
Fix For: 4.2.3
Attachments: PutObjectStoreDirHere.zip
I have a custom JCA 1.5 compliant resource adapter (called DTPRA) that I am attempting to
test with JBoss Application Server 4.0.5 and JBoss Transactions 4.2.2. DTPRA has already
been successfully tested with JBoss 4.0.2 (without recovery) and with BEA WebLogic Server
9.0 and IBM WebSphere Application Server 6.0.1 (both with recovery).
For this scenario, I am using the JBoss Application Server "all" config with
the distributed JTA configured.
I ran a test with an inbound transaction to DTPRA using JCA 1.5 transaction inflow. This
worked fine with no errors or unexpected warnings.
I ran the same test again with a sleep in DTPRA code so I could test recovery.
Here is a high-level summary of what is happened:
1) DTPRA generated an XID and called XATerminator.prepare with this XID.
XATerminator.prepare returned XA_OK, as expected.
2) Everyone involved in the transaction is successfully logged.
3) Before calling XATerminator.commit, I killed the Java process running JBoss.
4) I restarted JBoss.
5) DTPRA called XATerminator.recover and it returned one XID. However, the XID did not
match the XID that DTPRA supplied earlier on the XATerminator.prepare call.
6) Later, DTPRA called XATerminator.commit with the the same XID supplied in step 1. This
failed with an XAException with an errorCode of XAER_INVAL.
In particular, DTPRA called XATerminator.prepare and XATerminator.commit with the
following XID:
0x44545031,
0xa08006092b81403f8176768f520000820400757e21,
0x06092b81403f815561ae73
where the first value is the format ID, the second value is the global transaction ID,
and the third value is the branch qualifier. All three values are hexadecimal values, not
printable ASCII characters.
The XID returned from XATerminator.recover is the following:
131075,
0x312d2d33666330326139663a3534623a34353736653366373a3935,
0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
That is, the global transaction ID is the ASCII string:
1--3fc02a9f_54b_4576e3f7_95
So, I have the following issues:
A) I expected the XID returned from XATerminator.recover to match the XID I supplied
earlier to XATerminator.prepare.
B) I expected the call to XATerminator.commit during recovery to succeed.
--
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
7045
days inactive
7064
days old
11 comments
3 participants
participants (3)
-
Mark Little (JIRA) -
Peter Johnson (JIRA)
-
Stephen Burdeau (JIRA)