April 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1556) provide way for Synchronization.afterCompletion callee to know if the Reaper thread is calling

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBTM-1556?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on JBTM-1556: ------------------------------------ When each coordinator handles the timeout, does it also cancel its subordinates (as if the subordinate is one of the resources)? Or is it more like the coordinator times out the subordinate (as a resource) which means blocking until the subordinate has completed the subordinate level (reaper) timing out of its (subordinate) resources? In other words, could the subordinate coordinator Synchronization.afterCompletion() be called from a transport thread ever or only from a reaper thread? > provide way for Synchronization.afterCompletion callee to know if the Reaper thread is calling > ---------------------------------------------------------------------------------------------- > > Key: JBTM-1556 > URL: https://issues.jboss.org/browse/JBTM-1556 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 4.17.3 > Reporter: Scott Marlow > Assignee: Tom Jenkinson > Fix For: 4.17.4, 5.0.0.M3 > > > When the Synchronization.afterCompletion is invoked for EE JPA containers, knowledge of whether the current thread is the Reaper thread (cancelling the transaction from a background thread). > The fix to this jira will help with handling the [JPA 2.1 container concurrency requirements|http://java.net/projects/jpa-spec/lists/jsr338-experts/archi...]. > Please implement the solution makes the most sense to you, as this will introduce an additional dependency between other systems and JBossTM/JBossTS that depend on the solution, that will likely be around for a long time. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1627) restat-simple quickstart failure: NoClassDefFoundError: groovy/lang/GroovyClassLoader

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1627?page=com.atlassian.jira.plugin.... ] Paul Robinson resolved JBTM-1627. --------------------------------- Resolution: Won't Fix This error is benign. The test failed for some other reason. Investigating... > restat-simple quickstart failure: NoClassDefFoundError: groovy/lang/GroovyClassLoader > ------------------------------------------------------------------------------------- > > Key: JBTM-1627 > URL: https://issues.jboss.org/browse/JBTM-1627 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, REST > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M3 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > See: http://172.17.131.2/view/Narayana+BlackTie/job/btny-narayana-quickstarts-... -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1627) restat-simple quickstart failure: NoClassDefFoundError: groovy/lang/GroovyClassLoader

by Paul Robinson (JIRA)

Paul Robinson created JBTM-1627: ----------------------------------- Summary: restat-simple quickstart failure: NoClassDefFoundError: groovy/lang/GroovyClassLoader Key: JBTM-1627 URL: https://issues.jboss.org/browse/JBTM-1627 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Demonstrator, REST Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 5.0.0.M3 See: http://172.17.131.2/view/Narayana+BlackTie/job/btny-narayana-quickstarts-... -- 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

1
0
0 / 0

[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?page=com.atlassian.jira.plugin.... ] Work on JBTM-1407 started by Gytis Trikleris. > 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: Critical > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1487) TXBridge 4.17 branch quickstart has 5.0.0.M2-SNAPSHOT dependencies

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1487?focusedWorklogId=12428996&page=... ] Paul Robinson logged work on JBTM-1487: --------------------------------------- Author: Paul Robinson Created on: 10/Apr/13 10:16 AM Start Date: 10/Apr/13 10:16 AM Worklog Time Spent: 10 minutes Issue Time Tracking ------------------- Remaining Estimate: 0 minutes (was: 1 hour) Time Spent: 10 minutes Worklog Id: (was: 12428996) > TXBridge 4.17 branch quickstart has 5.0.0.M2-SNAPSHOT dependencies > ------------------------------------------------------------------ > > Key: JBTM-1487 > URL: https://issues.jboss.org/browse/JBTM-1487 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, TxBridge, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 4.17.4 > > Original Estimate: 1 hour > Time Spent: 10 minutes > Remaining Estimate: 0 minutes > > See: > https://github.com/jbosstm/quickstart/blob/4.17/TXBridge/wsat-jta-multi_h... > Check for others. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1487) TXBridge 4.17 branch quickstart has 5.0.0.M2-SNAPSHOT dependencies

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1487?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1487: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jbosstm/quickstart/pull/71 > TXBridge 4.17 branch quickstart has 5.0.0.M2-SNAPSHOT dependencies > ------------------------------------------------------------------ > > Key: JBTM-1487 > URL: https://issues.jboss.org/browse/JBTM-1487 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, TxBridge, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 4.17.4 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > See: > https://github.com/jbosstm/quickstart/blob/4.17/TXBridge/wsat-jta-multi_h... > Check for others. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1487) TXBridge 4.17 branch quickstart has 5.0.0.M2-SNAPSHOT dependencies

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1487?page=com.atlassian.jira.plugin.... ] Work on JBTM-1487 started by Paul Robinson. > TXBridge 4.17 branch quickstart has 5.0.0.M2-SNAPSHOT dependencies > ------------------------------------------------------------------ > > Key: JBTM-1487 > URL: https://issues.jboss.org/browse/JBTM-1487 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Demonstrator, TxBridge, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 4.17.4 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > See: > https://github.com/jbosstm/quickstart/blob/4.17/TXBridge/wsat-jta-multi_h... > Check for others. -- 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

1
0
0 / 0

[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/10/13 10:04 AM: --------------------------------------------------------------- Your fix looks like it would work. But I think the main issue is... Why does XTSServiceTestRunnerBean.start() fire before XTSManagerService.start() has completed? XTSServiceTestRunnerBean is a ServletContextListener deployed as part of an application. I would have expected this application (xtstest.war) to wait for the XTS subsystem to have started before it starts. Maybe something has changed around this, which explains why we have only just started seeing the problem. I think the better solution would be to find out why this is happening and get the dependency working. was (Author: paul.robinson): Your fix looks like it would work. But I think the main issue is... Why does XTSServiceTestRunnerBean.start() fire before XTSManagerService.start() has completed? XTSServiceTestRunnerBean is a ServletContextListener deployed as part of an application. I would have expected this application (xtstest.war) to wait for the XTS subsystem to have started before it starts. Maybe something has changed around this, which explains why we have only just started seeing the problem. > "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, 5 months

1
0
0 / 0

[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: ------------------------------------- Your fix looks like it would work. But I think the main issue is... Why does XTSServiceTestRunnerBean.start() fire before XTSManagerService.start() has completed? XTSServiceTestRunnerBean is a ServletContextListener deployed as part of an application. I would have expected this application (xtstest.war) to wait for the XTS subsystem to have started before it starts. Maybe something has changed around this, which explains why we have only just started seeing the problem. > "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, 5 months

1
0
0 / 0

[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 commented on JBTM-1622: ------------------------------------- Fix is to ensure Arquillian uses "java -server". See discussion here: https://community.jboss.org/message/807403 > 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: Minor > Fix For: 5.0.0.M3 > > > 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, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2013