[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 commented on JBTM-1522:
---------------------------------------
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, 5 months
[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1522:
--------------------------------
Attachment: 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.txt
com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt
com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt
com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt
Here's the logs from the current failures on the narayana-JBTM-1522 job.
> "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, 5 months
[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in LockManager.propagate
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1602:
-----------------------------------
I've run another 1000 tests, with the same results:
Buildfile: /Users/marklittle/github/narayana/qa/run-tests.xml
foobar:
[echo] Running junit test group jtsremote from basedir=/Users/marklittle/github/narayana/qa
[junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 79.101 sec
BUILD SUCCESSFUL
Total time: 1 minute 20 seconds
I'll check in the changes necessary for this fix, but will ask Mike to run on the test machines before (hopefully) closing the issue.
> Determine why 4 locks acquired in LockManager.propagate
> -------------------------------------------------------
>
> Key: JBTM-1602
> URL: https://issues.jboss.org/browse/JBTM-1602
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Mark Little
> Assignee: Mark Little
>
--
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, 5 months
[JBoss JIRA] (JBTM-1610) Typo in method names of SerializableXAResourceDeserializer interface
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1610?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1610:
-----------------------------------
Yes, it's a public API so changing in 4.17 branch is not possible. But methods could be deprecated and correct spellings used elsewhere.
> Typo in method names of SerializableXAResourceDeserializer interface
> --------------------------------------------------------------------
>
> Key: JBTM-1610
> URL: https://issues.jboss.org/browse/JBTM-1610
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.3, 5.0.0.M2
> Reporter: jaikiran pai
> Assignee: Tom Jenkinson
> Priority: Optional
>
> The 2 methods in SerializableXAResourceDeserializer are named these:
> {code}
> ...
> public boolean canDeserialze(String className);
> ...
> public XAResource deserialze(ObjectInputStream ois) throws IOException, ClassNotFoundException;
> {code}
> Notice the typo - a missing "i" in deserialize.
> I guess it's too late or a bit too much to change those methods now since that interface might already be in use, in different projects. Hence, marking this JIRA as "Optional"
--
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, 5 months
[JBoss JIRA] (JBTM-1609) Certain XAResourceRecord constructors don't take into account configured SerializableXAResourceDeserializer(s)
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1609?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1609:
-----------------------------------
I believe it was Jonathan who added the SerializableXAResourceDeserializer, so check with him before applying any patch.
> Certain XAResourceRecord constructors don't take into account configured SerializableXAResourceDeserializer(s)
> --------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1609
> URL: https://issues.jboss.org/browse/JBTM-1609
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.3, 5.0.0.M2
> Reporter: jaikiran pai
> Assignee: Tom Jenkinson
>
> Certain XAResourceRecord constructors don't initialize the list of SerializableXAResourceDeserializer that's maintained in the XAResourceRecord. As a result, during restoring the state of the record, the XAResourceRecord will not be aware of the configured SerializableXAResourceDeserializer(s) and can end up not being able to deserialize the XAResource within that record.
--
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, 5 months
[JBoss JIRA] (JBTM-1610) Typo in method names of SerializableXAResourceDeserializer interface
by jaikiran pai (JIRA)
jaikiran pai created JBTM-1610:
----------------------------------
Summary: Typo in method names of SerializableXAResourceDeserializer interface
Key: JBTM-1610
URL: https://issues.jboss.org/browse/JBTM-1610
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Recovery
Affects Versions: 5.0.0.M2, 4.17.3
Reporter: jaikiran pai
Assignee: Tom Jenkinson
Priority: Optional
The 2 methods in SerializableXAResourceDeserializer are named these:
{code}
...
public boolean canDeserialze(String className);
...
public XAResource deserialze(ObjectInputStream ois) throws IOException, ClassNotFoundException;
{code}
Notice the typo - a missing "i" in deserialize.
I guess it's too late or a bit too much to change those methods now since that interface might already be in use, in different projects. Hence, marking this JIRA as "Optional"
--
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, 5 months
[JBoss JIRA] (JBTM-1609) Certain XAResourceRecord constructors don't take into account configured SerializableXAResourceDeserializer(s)
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/JBTM-1609?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on JBTM-1609:
------------------------------------
Pull requests containing a fix have been sent to both 4.17 and master branches.
> Certain XAResourceRecord constructors don't take into account configured SerializableXAResourceDeserializer(s)
> --------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1609
> URL: https://issues.jboss.org/browse/JBTM-1609
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.17.3, 5.0.0.M2
> Reporter: jaikiran pai
> Assignee: Tom Jenkinson
>
> Certain XAResourceRecord constructors don't initialize the list of SerializableXAResourceDeserializer that's maintained in the XAResourceRecord. As a result, during restoring the state of the record, the XAResourceRecord will not be aware of the configured SerializableXAResourceDeserializer(s) and can end up not being able to deserialize the XAResource within that record.
--
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, 5 months
[JBoss JIRA] (JBTM-1609) Certain XAResourceRecord constructors don't take into account configured SerializableXAResourceDeserializer(s)
by jaikiran pai (JIRA)
jaikiran pai created JBTM-1609:
----------------------------------
Summary: Certain XAResourceRecord constructors don't take into account configured SerializableXAResourceDeserializer(s)
Key: JBTM-1609
URL: https://issues.jboss.org/browse/JBTM-1609
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Recovery
Affects Versions: 5.0.0.M2, 4.17.3
Reporter: jaikiran pai
Assignee: Tom Jenkinson
Certain XAResourceRecord constructors don't initialize the list of SerializableXAResourceDeserializer that's maintained in the XAResourceRecord. As a result, during restoring the state of the record, the XAResourceRecord will not be aware of the configured SerializableXAResourceDeserializer(s) and can end up not being able to deserialize the XAResource within that record.
--
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, 5 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:
---------------------------------
Gytis,
can you mail me the failed test output file ? you can find in the XTS/localunit/crash-recovery-tests/target/surefire-reports.
Thanks,
Amos
> "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
>
>
> 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, 5 months