[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:
---------------------------------
https://community.jboss.org/message/807912#807912
> "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: 4.17.4, 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, 7 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 commented on JBTM-1522:
-------------------------------------
Amos,
Can you provide a link to the discussion? I couldn't find it.
Paul.
> "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: 4.17.4, 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, 7 months
[JBoss JIRA] (JBTM-1629) Refactor TXBridge pom to inherit versions from root pom
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1629?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1629:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Refactor TXBridge pom to inherit versions from root pom
> -------------------------------------------------------
>
> Key: JBTM-1629
> URL: https://issues.jboss.org/browse/JBTM-1629
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System, TxBridge
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M3
>
> Original Estimate: 1 hour
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> There are lots of hard-coded versions in this pom. Many of which are severely outdated.
> There's also quite a bit of mess in this pom. Empty properties, unused properties, commented out stuff. This should also be removed.
--
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, 7 months
[JBoss JIRA] (JBTM-1622) StackOverflowError when loading org.jboss.ws.common:main module
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1622?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1622:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> StackOverflowError when loading org.jboss.ws.common:main module
> ---------------------------------------------------------------
>
> Key: JBTM-1622
> URL: https://issues.jboss.org/browse/JBTM-1622
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Time Spent: 1 day
> Remaining Estimate: 0 minutes
>
> See: http://172.17.131.2/job/narayana/229
> {noformat}
> Tests in error:
> testRollback(org.jboss.as.test.xts.simple.wsat.client.WSATTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testCommit(org.jboss.as.test.xts.simple.wsat.client.WSATTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testCannotComplete(org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase): Unexpected exception, expected<com.arjuna.wst.TransactionRolledBackException> but was<java.lang.Exception>
> testCancel(org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testSuccess(org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testCancel(org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> testSuccess(org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase): Receiver[com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.][com.arjuna.webservices.util.InvalidEnumerationException: ARJUNA042002: Invalid fault type enumeration: No namespace on "html" element. You must send a SOAP request.(..)
> {noformat}
--
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, 7 months
[JBoss JIRA] (JBTM-1621) Failed to create service in XTS interop and recovery tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1621?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1621:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Failed to create service in XTS interop and recovery tests
> ----------------------------------------------------------
>
> Key: JBTM-1621
> URL: https://issues.jboss.org/browse/JBTM-1621
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Time Spent: 1 day
> Remaining Estimate: 0 minutes
>
> http://172.17.131.2/job/narayana/227/console
> http://172.17.131.2/job/narayana/228/console
> {noformat}
> javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:149)
> at org.jboss.wsf.stack.cxf.client.ProviderImpl$JBossWSServiceImpl.<init>(ProviderImpl.java:484) [jbossws-cxf-client-4.2.0.Alpha1.jar:4.2.0.Alpha1]
> at org.jboss.wsf.stack.cxf.client.ProviderImpl.createServiceDelegate(ProviderImpl.java:170) [jbossws-cxf-client-4.2.0.Alpha1.jar:4.2.0.Alpha1]
> at javax.xml.ws.Service.<init>(Service.java:57) [jboss-jaxws-api_2.2_spec-2.0.1.Final.jar:2.0.1.Final]
> at com.jboss.transaction.txinterop.webservices.atinterop.generated.ParticipantService.<init>(ParticipantService.java:65) [classes:]
> at com.jboss.transaction.txinterop.webservices.atinterop.client.ATInteropClient.getParticipantService(ATInteropClient.java:86) [classes:]
> at com.jboss.transaction.txinterop.webservices.atinterop.client.ATInteropClient.getParticipantPort(ATInteropClient.java:116) [classes:]
> at com.jboss.transaction.txinterop.webservices.atinterop.client.AsyncParticipantClient.sendRetryCommit(AsyncParticipantClient.java:402) [classes:]
> at com.jboss.transaction.txinterop.webservices.atinterop.AsyncParticipantStub.retryCommit(AsyncParticipantStub.java:421) [classes:]
> at com.jboss.transaction.txinterop.interop.ATTestCase.testAT5_4(ATTestCase.java:429) [classes:]
> at com.jboss.transaction.txinterop.interop.ATTest.testAT5_4(ATTest.java:129) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) [arquillian-service:]
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [arquillian-service:]
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) [arquillian-service:]
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-service:]
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) [:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) [:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) [:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-service:]
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) [arquillian-service:]
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) [arquillian-service:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) [arquillian-service:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) [arquillian-service:]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) [arquillian-service:]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) [arquillian-service:]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) [arquillian-service:]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) [arquillian-service:]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) [arquillian-service:]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) [arquillian-service:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [arquillian-service:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [arquillian-service:]
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) [arquillian-service:]
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128) [arquillian-service:]
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107) [arquillian-service:]
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:217) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) [rt.jar:1.7.0_17]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:100)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:199)
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:147)
> ... 100 more
> Caused by: javax.wsdl.WSDLException: WSDLException (at /definitions/binding/operation[1]/input): faultCode=INVALID_WSDL: Encountered illegal extension attribute 'message'. Extension attributes must be in a namespace other than WSDL's.
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseExtensibilityAttributes(WSDLReaderImpl.java:1398) [wsdl4j-1.6.3.jar:1.6.3]
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseBindingInput(WSDLReaderImpl.java:1154) [wsdl4j-1.6.3.jar:1.6.3]
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseBindingOperation(WSDLReaderImpl.java:1032) [wsdl4j-1.6.3.jar:1.6.3]
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseBinding(WSDLReaderImpl.java:982) [wsdl4j-1.6.3.jar:1.6.3]
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(WSDLReaderImpl.java:332) [wsdl4j-1.6.3.jar:1.6.3]
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2352) [wsdl4j-1.6.3.jar:1.6.3]
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2338) [wsdl4j-1.6.3.jar:1.6.3]
> at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:260)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:205)
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:98)
> ... 102 more
> {noformat}
--
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, 7 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 commented on JBTM-1522:
-------------------------------------
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61/1755/artifac...
> "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: 4.17.4, 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, 7 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 edited comment on JBTM-1522 at 4/12/13 5:11 AM:
--------------------------------------------------------------
Happening in 4.17 too:
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61/1755/artifac...
was (Author: paul.robinson):
http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61/1755/artifac...
> "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: 4.17.4, 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, 7 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:
--------------------------------
Fix Version/s: 4.17.4
> "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: 4.17.4, 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, 7 months