[JBoss JIRA] (JBTM-1405) idlj issue when building on Raspberry Pi
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1405?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1405:
----------------------------------
Original Estimate: 0 minutes
Remaining Estimate: 0 minutes
> idlj issue when building on Raspberry Pi
> ----------------------------------------
>
> Key: JBTM-1405
> URL: https://issues.jboss.org/browse/JBTM-1405
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS
> Affects Versions: 4.17.3
> Environment: Raspberry Pi with stock distribution installed and openjdk 6.
> Reporter: Mark Little
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> Early in the build we get ...
> [INFO] Processing 3 grammar files to /home/pi/narayana/ArjunaJTS/idl/idlj/target/generated-sources/idl
> [INFO] [ERROR] /home/pi/narayana/ArjunaJTS/idl/src/main/idl/omg/CosTransactions.idl (line 35): java.io.FileNotFoundException: orb.idl
> #include <orb.idl>
> ^
> [ERROR] /home/pi/narayana/ArjunaJTS/idl/src/main/idl/omg/CosTransactions.idl (line 35): java.io.FileNotFoundException: orb.idl
> #include <orb.idl>
> ^
> [INFO] [ERROR] /home/pi/narayana/ArjunaJTS/idl/src/main/idl/omg/CosTransactions.idl (line 35): java.io.FileNotFoundException: orb.idl
> #include <orb.idl>
> ^
> [ERROR] /home/pi/narayana/ArjunaJTS/idl/src/main/idl/omg/CosTransactions.idl (line 35): java.io.FileNotFoundException: orb.idl
> #include <orb.idl>
> ^
> [INFO] [ERROR] /home/pi/narayana/ArjunaJTS/idl/src/main/idl/omg/CosTransactions.idl (line 35): java.io.FileNotFoundException: orb.idl
> #include <orb.idl>
> ^
> [ERROR] /home/pi/narayana/ArjunaJTS/idl/src/main/idl/omg/CosTransactions.idl (line 35): java.io.FileNotFoundException: orb.idl
> #include <orb.idl>
> ^
> And eventually this results in ...
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 4:03:24.556s
> [INFO] Finished at: Sat Dec 22 20:32:47 UTC 2012
> [INFO] Final Memory: 38M/105M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.9:test (surefire-idlj) on project jts: Execution surefire-idlj of goal org.apache.maven.plugins:maven-surefire-plugin:2.9:test failed: java.lang.reflect.InvocationTargetException; nested exception is java.lang.reflect.InvocationTargetException: null: org/omg/CosTransactions/ResourceOperations: org.omg.CosTransactions.ResourceOperations -> [Help 1]
> It would also be good if there was a build-time switch to disable using idlj. Building with the idlj option at the start (as mentioned in the README) would imply that this is the way to go and that building just using jts therefore only uses jacorb, but it seems that the jts rule builds with both orbs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1407) Have a build option that builds JTS only against JacORB or IDLJ, but not both.
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1407?focusedWorklogId=12428937&page=... ]
Gytis Trikleris logged work on JBTM-1407:
-----------------------------------------
Author: Gytis Trikleris
Created on: 02/Apr/13 3:52 AM
Start Date: 02/Apr/13 3:51 AM
Worklog Time Spent: 1 minute
Issue Time Tracking
-------------------
Remaining Estimate: 3 days (was: 1 hour)
Time Spent: 3 days, 1 hour, 51 minutes (was: 3 days, 1 hour, 50 minutes)
Worklog Id: (was: 12428937)
> Have a build option that builds JTS only against JacORB or IDLJ, but not both.
> ------------------------------------------------------------------------------
>
> Key: JBTM-1407
> URL: https://issues.jboss.org/browse/JBTM-1407
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System, JTS
> Affects Versions: 4.17.3
> Reporter: Mark Little
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.0.0.M3
>
> Time Spent: 3 days, 1 hour, 51 minutes
> Remaining Estimate: 3 days
>
> This boils down to supporting two new profiles:
> ./build.sh -P jts-jacorb
> ./build.sh -P jts-idlj
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1482) If a naughty afterCompletion sync throws an exception, log the exception call stack
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1482?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1482:
----------------------------------
Original Estimate: 30 minutes
Remaining Estimate: 30 minutes
> If a naughty afterCompletion sync throws an exception, log the exception call stack
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1482
> URL: https://issues.jboss.org/browse/JBTM-1482
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Scott Marlow
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.0.0.M3
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> Currently, when this happens with AS, I see:
> {quote}
> 2013-02-18 16:24:43,837|WARN |[com.arjuna.ats.jta]|(ThreadId: Transaction Reaper Worker 221)|ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization@634ef5a7 with exception: java.lang.NullPointerException
> {quote}
> From a related email conversation:
> {quote}
> Here's our Logger code:
> @Message(id = 16029, value = "SynchronizationImple.afterCompletion - failed for {0} with exception", format = MESSAGE_FORMAT)
> @LogMessage(level = WARN)
> public void warn_resources_arjunacore_SynchronizationImple(String arg0, @Cause() Throwable arg1);
> Here is where we call our logger:
> jtaLogger.i18NLogger.warn_resources_arjunacore_SynchronizationImple(_theSynch.toString(), e);
> Maybe the message should have the {1} in it, i.e. it change it like so:
> "SynchronizationImple.afterCompletion - failed for {0} with exception {1}"
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1598) version tags missed for all the sub-components
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1598?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1598:
----------------------------------
Original Estimate: 1 hour
Remaining Estimate: 1 hour
> version tags missed for all the sub-components
> ----------------------------------------------
>
> Key: JBTM-1598
> URL: https://issues.jboss.org/browse/JBTM-1598
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Weinan Li
> Assignee: Gytis Trikleris
> Fix For: 4.17.4, 5.0.0.M3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Hi Tom, the problem I've found is that all the dependencies of its own components are lack of version section. For example:
> {code}
> <dependencies>
> <dependency>
> <groupId>org.jboss.jbossts</groupId>
> <artifactId>common</artifactId>
> </dependency>
> </dependencies>
> {code}
> Should be:
> {code}
> <dependencies>
> <dependency>
> <groupId>org.jboss.jbossts</groupId>
> <artifactId>common</artifactId>
> <version>${project.version}</version>
> </dependency>
> </dependencies>
> {code}
> Could you please help to add these tags? Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-1522:
---------------------------------
Thanks Paul and Gytis,
It looks like the recovery manager is null when registering TestATRecoveryModule by checking these logs.
see codes in org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule
{code}
/**
* called by the service startup code before the recovery module is added to the recovery managers
* module list
*/
public void install()
{
// the manager is needed by both the participant or the coordinator recovery modules so whichever
// one gets there first creates it. No synchronization is needed as modules are only ever
// installed in a single thread
XTSATRecoveryManager atRecoveryManager = XTSATRecoveryManager.getRecoveryManager();
if (atRecoveryManager == null) {
atRecoveryManager = new XTSATRecoveryManagerImple(_recoveryStore);
XTSATRecoveryManager.setRecoveryManager(atRecoveryManager);
}
// Subordinate Coordinators register durable participants with their parent transaction so
// we need to add an XTSATRecoveryModule which knows about the registered participants
subordinateRecoveryModule = new XTSATSubordinateRecoveryModule();
atRecoveryManager.registerRecoveryModule(subordinateRecoveryModule);
}
{code}
XTSServiceTestRunner could start before the setRecoveryManager and it can not register the recovery module.
the simple fix looks like to check the XTSATRecoveryManager.getRecoveryManager() until it is not null.
> "no XTS application recovery module found" during XTS Recovery Tests
> --------------------------------------------------------------------
>
> Key: JBTM-1522
> URL: https://issues.jboss.org/browse/JBTM-1522
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Attachments: 2013-04-01_jbtm-1522_outputs.zip, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt
>
>
> See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/...
> Notice the following log is displayed repeatedly until the test gives up waiting for recovery:
> {code}
> WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0
> {code}
> This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular:
> {code}
> if (!found) {
> // we failed to find a helper to convert a participant record so log a warning
> // but leave it in the table for next time
> RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId());
> }
> {code}
> It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry?
> This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan...
> h4.Cunning Plan
> We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take:
> # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it.
> # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above.
> # Configure the job to run @hourly until it fails with this problem.
> # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build.
> # Boot the AS and confirm that the issue is reproduced.
> # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue.
> # Attach a debugger to find out what the problem is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1522:
----------------------------------
Attachment: 2013-04-01_jbtm-1522_outputs.zip
> "no XTS application recovery module found" during XTS Recovery Tests
> --------------------------------------------------------------------
>
> Key: JBTM-1522
> URL: https://issues.jboss.org/browse/JBTM-1522
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Attachments: 2013-04-01_jbtm-1522_outputs.zip, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt
>
>
> See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/...
> Notice the following log is displayed repeatedly until the test gives up waiting for recovery:
> {code}
> WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0
> {code}
> This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular:
> {code}
> if (!found) {
> // we failed to find a helper to convert a participant record so log a warning
> // but leave it in the table for next time
> RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId());
> }
> {code}
> It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry?
> This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan...
> h4.Cunning Plan
> We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take:
> # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it.
> # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above.
> # Configure the job to run @hourly until it fails with this problem.
> # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build.
> # Boot the AS and confirm that the issue is reproduced.
> # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue.
> # Attach a debugger to find out what the problem is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris edited comment on JBTM-1522 at 4/1/13 3:18 PM:
---------------------------------------------------------------
http://172.17.131.2/job/narayana/221
http://172.17.131.2/job/narayana-JBTM-1522/92
http://172.17.131.2/job/narayana-JBTM-1522/100
http://172.17.131.2/job/narayana-JBTM-1522/110
http://172.17.131.2/job/narayana-JBTM-1522/118
http://172.17.131.2/job/narayana-JBTM-1522/122
http://172.17.131.2/job/narayana-JBTM-1522/130
All logs in 2013-04-01_jbtm-1522_outputs.zip
was (Author: gytis):
http://172.17.131.2/job/narayana/221
http://172.17.131.2/job/narayana-JBTM-1522/92
http://172.17.131.2/job/narayana-JBTM-1522/100
http://172.17.131.2/job/narayana-JBTM-1522/110
http://172.17.131.2/job/narayana-JBTM-1522/118
http://172.17.131.2/job/narayana-JBTM-1522/122
http://172.17.131.2/job/narayana-JBTM-1522/130
> "no XTS application recovery module found" during XTS Recovery Tests
> --------------------------------------------------------------------
>
> Key: JBTM-1522
> URL: https://issues.jboss.org/browse/JBTM-1522
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Attachments: 2013-04-01_jbtm-1522_outputs.zip, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt
>
>
> See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/...
> Notice the following log is displayed repeatedly until the test gives up waiting for recovery:
> {code}
> WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0
> {code}
> This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular:
> {code}
> if (!found) {
> // we failed to find a helper to convert a participant record so log a warning
> // but leave it in the table for next time
> RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId());
> }
> {code}
> It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry?
> This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan...
> h4.Cunning Plan
> We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take:
> # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it.
> # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above.
> # Configure the job to run @hourly until it fails with this problem.
> # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build.
> # Boot the AS and confirm that the issue is reproduced.
> # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue.
> # Attach a debugger to find out what the problem is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris edited comment on JBTM-1522 at 4/1/13 3:04 PM:
---------------------------------------------------------------
http://172.17.131.2/job/narayana/221
http://172.17.131.2/job/narayana-JBTM-1522/92
http://172.17.131.2/job/narayana-JBTM-1522/100
http://172.17.131.2/job/narayana-JBTM-1522/110
http://172.17.131.2/job/narayana-JBTM-1522/118
http://172.17.131.2/job/narayana-JBTM-1522/122
http://172.17.131.2/job/narayana-JBTM-1522/130
was (Author: gytis):
http://172.17.131.2/job/narayana/221
> "no XTS application recovery module found" during XTS Recovery Tests
> --------------------------------------------------------------------
>
> Key: JBTM-1522
> URL: https://issues.jboss.org/browse/JBTM-1522
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Attachments: com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt
>
>
> See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/...
> Notice the following log is displayed repeatedly until the test gives up waiting for recovery:
> {code}
> WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0
> {code}
> This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular:
> {code}
> if (!found) {
> // we failed to find a helper to convert a participant record so log a warning
> // but leave it in the table for next time
> RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId());
> }
> {code}
> It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry?
> This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan...
> h4.Cunning Plan
> We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take:
> # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it.
> # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above.
> # Configure the job to run @hourly until it fails with this problem.
> # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build.
> # Boot the AS and confirm that the issue is reproduced.
> # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue.
> # Attach a debugger to find out what the problem is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months