September 2010 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-792) Race condition between thread sending COMPLETE and thread handling NOT_COMPLETED causes error

by Andrew Dinn (JIRA)

Race condition between thread sending COMPLETE and thread handling NOT_COMPLETED causes error --------------------------------------------------------------------------------------------- Key: JBTM-792 URL: https://jira.jboss.org/browse/JBTM-792 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.12.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.13.0 BA CoordinatorCompletion participants suffer a timeout failure if they call BAParticipantManager.cannotComplete() underneath a call to BAWithCCParticipant.complete(). This problem arises because of a race condition on the coordinator side between the thread sending the COMPLETE request and the thread handling the NOT_COMPLETING response. AN error on the coordinator side means that the participant does not get sent the expected NOT_COMPLETED acknowledgement. Here is how it goes worng: The sending thread dispatches a COMPLETED message then waits on a change to the coordinator engine state. The participant side receives COMPLETED and the participant calls cannotComplete, sending NOT_COMPLETING The handler thread is started in response to an incoming NOT_COMPLETING message. The first thing it does is set the coordinator engine state to NOT_COMPLETING. Chequered flag raised! The sending thread wakes up and finds that the state has transitioned to something other than COMPLETED. If the complete was done as part of a client close request it tries to notify the coordinator to abort In the meantime the handler tries to notify the coordinator that the participant cannot complete. Chequered flag down! If the sender wins the race the handler thread finds an ABORTED coordinator and blows up with a WrongState exception which means it does not send NOT_COMPLETED (also, it does nto clear out the transaction). n.b. this is exactly the same problem as was dealt with earlier when fail requests were being sent during COMPLETE/CANCEL/COMPENSATE processing. -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-791) BA Termination Partiicpant soap faults being sent with wrong action

by Andrew Dinn (JIRA)

BA Termination Partiicpant soap faults being sent with wrong action ------------------------------------------------------------------- Key: JBTM-791 URL: https://jira.jboss.org/browse/JBTM-791 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.12.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.14.0 The action used by the ARJTX Termination Participant client is wrongly defined. It is currently "http://schemas.arjuna.com/ws/2005/10/wsarjtx/soapFault" where it should actually be "http://schemas.arjuna.com/ws/2005/10/wsarjtx/Fault" -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-784) incorrect ORB initialization

by Jonathan Halliday (JIRA)

incorrect ORB initialization ---------------------------- Key: JBTM-784 URL: https://jira.jboss.org/browse/JBTM-784 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS, Recovery Affects Versions: 4.12.0 Reporter: Jonathan Halliday Assignee: Mark Little Fix For: 4.13.0 When running the TransactionManager and RecoveryManager in the same JVM, the ORB initialization incorrectly attempts to setup the ORB twice: WARN: ARJUNA-22251 The ORBManager is already associated with an ORB/OA. The correct model is one ORB and two POAs, whereas we currently have two ORBs. See ORBManager; RecoveryORBManager (both have ORB field); ORB/InternalORB (why the subclass?) method initORB->InitLoader->ORBSetup; JacOrbRCServiceInit -- 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

14 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBTM-786) XTS participant API should allow participant to complete in 2 phases

by Andrew Dinn (JIRA)

XTS participant API should allow participant to complete in 2 phases -------------------------------------------------------------------- Key: JBTM-786 URL: https://jira.jboss.org/browse/JBTM-786 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.12.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Currently, when an XTS participant completes it is expected 1) to persist all its changes and then allow the XTS participant management code 2) to log a recovery record and 3) to notify the coordinator that the participant completed. The exact path taken varies depending upon the participant type but the sequence is always the same. So, a participant completion participant is expected to persist its changes and call the BAManager completed method. This initiates creation and logging of the recovery record and dispatch of a COMPLETED message to the coordinator. A coordinator completion participant is not expected to persist its changes until its completed method is called. It is after this call returns that the XTS participant management code creates and logs the recovery record and dispatches a COMMITTED message. This leaves a window open between 1 and 2 where a crash may occur, leaving persistent changes committed with no information available describing how to compensate them. In order to close this window a 2 phase protocol must be used when saving the changes: 1) participant prepares changes to be persisted 2) XTS participant manager logs recovery record 3) participant commits changes 4) XTS participant manager dispatches COMPLETED message This ensures that changes are only actually committed to persistent storage when a recovery record is in place in the log, a precondition for the commit to be safe. It also ensures that the coordinator cannot be told the participant has completed unless the changes truly have been persisted. However, this is not the full story. Clearly, this only works if the (application-specific) participant recovery module takes steps during recovery to resolve crashes between stages 1 and 2 or stages 2 and 3. Note that a crash between stages 3 and 4 is already handled by the existing recovery code. So, the extra steps required are as follows: The participant recovery module must be able to detect uncommitted change sets at recovery time. The recovery record for a participant must include information allowing the associated unprepared change set to be identified. At the first participant recovery pass when presented with a recovery record for participant p with change set u - if u no longer exists then it has been committed so simply recreate p, allowing COMPLETED to be resent - if u still exists then a crash occurred between stages 2 and 3 so, either commit the changes and recreate p or roll back the changes and reject the recovery record (causing it to be garbage collected). In the former case this is safe because the changes have been completed as expected. In the latter case this is safe because the coordinator will not have seen a COMPLETED message so any attempt to close the activity will fail (if this is a coordinator completion participant and the coordinator resends COMPLETE it will get an unknown participant fault). A cancel request will proceed without error because of presumed abort. After the first participant recovery pass has completed any change set u' which has not been rolled forward must be present because of a crash between stages 1 and 2. Thsi situation can be handled by rolling back the changes. Once again this is safe because the coordinator will not have seen a COMPLETED message. Once this is fixed the demo should be updated to ensure that it uses this API. -- 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

14 years, 3 months

1
2
0 / 0

[JBoss JIRA] Deleted: (JBTM-768) Convert Transactions ArjunaCore Release Notes to DITA

by Misty Stanley-Jones (JIRA)

[ https://jira.jboss.org/browse/JBTM-768?page=com.atlassian.jira.plugin.sys... ] Misty Stanley-Jones deleted JBTM-768: ------------------------------------- > Convert Transactions ArjunaCore Release Notes to DITA > ----------------------------------------------------- > > Key: JBTM-768 > URL: https://jira.jboss.org/browse/JBTM-768 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Misty Stanley-Jones > Assignee: Misty Stanley-Jones > -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBTM-766) Convert Transactions documentation to DITA

by Misty Stanley-Jones (JIRA)

[ https://jira.jboss.org/browse/JBTM-766?page=com.atlassian.jira.plugin.sys... ] Misty Stanley-Jones deleted JBTM-766: ------------------------------------- > Convert Transactions documentation to DITA > ------------------------------------------ > > Key: JBTM-766 > URL: https://jira.jboss.org/browse/JBTM-766 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Misty Stanley-Jones > Assignee: Misty Stanley-Jones > > Convert existing Transactions docs from OpenOffice .odt format to DITA. -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-779) Add refactored XTS Development Guide to XTS upstream documentation repo

by Misty Stanley-Jones (JIRA)

Add refactored XTS Development Guide to XTS upstream documentation repo ----------------------------------------------------------------------- Key: JBTM-779 URL: https://jira.jboss.org/browse/JBTM-779 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: XTS Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Deleted: (JBTM-767) Convert ArjunaCore Installation Guide to DITA

by Misty Stanley-Jones (JIRA)

[ https://jira.jboss.org/browse/JBTM-767?page=com.atlassian.jira.plugin.sys... ] Misty Stanley-Jones deleted JBTM-767: ------------------------------------- > Convert ArjunaCore Installation Guide to DITA > --------------------------------------------- > > Key: JBTM-767 > URL: https://jira.jboss.org/browse/JBTM-767 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Misty Stanley-Jones > Assignee: Misty Stanley-Jones > -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBTM-769) Convert ArjunaCore User Guide to DITA

by Misty Stanley-Jones (JIRA)

[ https://jira.jboss.org/browse/JBTM-769?page=com.atlassian.jira.plugin.sys... ] Misty Stanley-Jones deleted JBTM-769: ------------------------------------- > Convert ArjunaCore User Guide to DITA > ------------------------------------- > > Key: JBTM-769 > URL: https://jira.jboss.org/browse/JBTM-769 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Misty Stanley-Jones > Assignee: Misty Stanley-Jones > -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-700) Look at restructuring docs

by Mark Little (JIRA)

Look at restructuring docs -------------------------- Key: JBTM-700 URL: https://jira.jboss.org/jira/browse/JBTM-700 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Mark Little Assignee: Mark Little Fix For: 4.11.0 -- 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

14 years, 3 months

2
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues September 2010