[JBoss JIRA] (JBTM-1078) Failure to parse default-jbossts-properties.xml on JBossAS boot
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1078:
-----------------------------------
Summary: Failure to parse default-jbossts-properties.xml on JBossAS boot
Key: JBTM-1078
URL: https://issues.jboss.org/browse/JBTM-1078
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Paul Robinson
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 4.16.3
To reproduce:
# cd to 4.16.3 tag of narayana
# Set version to 4.16.3.Final in the build.xml
# ant -Dpublican=false -DskipTests=true
# ant mvn-local-repository
# Download JBossAS 7.1.1 from https://github.com/jbossas/jboss-as/zipball/7.1.1.Final
# unzip
# edit pom.xml and set jbossts version to 4.16.3.Final
# mvn install -DskipTests=true
# cd ./build/target/jboss-as-7.1.1.Final
# sh bin/standalone.sh
Observe boot error:
{code}
7:51:54,694 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 57) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")
ang.RuntimeException: java.lang.RuntimeException: unable to load properties from jar:file:/tmp/jboss-as-7.1.1.Final/build/target/jboss-as-7.1.1.Final/modules/org/jboss/jts/main/jbossjts-4.16.3.Final.jar!/default-jbossts-properties.xml
at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:81)
at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
at com.arjuna.ats.arjuna.common.arjPropertyManager.getCoreEnvironmentBean(arjPropertyManager.java:45)
at org.jboss.as.txn.service.CoreEnvironmentService.getValue(CoreEnvironmentService.java:53)
at org.jboss.as.txn.service.CoreEnvironmentService.setProcessImplementation(CoreEnvironmentService.java:102)
at org.jboss.as.txn.subsystem.TransactionSubsystemAdd.performCoreEnvironmentBootTime(TransactionSubsystemAdd.java:309)
at org.jboss.as.txn.subsystem.TransactionSubsystemAdd.performBoottime(TransactionSubsystemAdd.java:172)
at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:57) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:50) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:311) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
Caused by: java.lang.RuntimeException: unable to load properties from jar:file:/tmp/jboss-as-7.1.1.Final/build/target/jboss-as-7.1.1.Final/modules/org/jboss/jts/main/jbossjts-4.16.3.Final.jar
!/default-jbossts-properties.xml
at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:110)
at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
... 16 more
Caused by: java.lang.IllegalArgumentException: Invalid index 0; current element has only 0 attributes
at com.ctc.wstx.sr.AttributeCollector.throwIndex(AttributeCollector.java:1018)
at com.ctc.wstx.sr.AttributeCollector.getValue(AttributeCollector.java:355)
at com.ctc.wstx.sr.BasicStreamReader.getAttributeValue(BasicStreamReader.java:607)
at com.arjuna.common.util.propertyservice.PropertiesFactory.loadFromXML(PropertiesFactory.java:188)
at com.arjuna.common.util.propertyservice.PropertiesFactory.loadFromFile(PropertiesFactory.java:145)
at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:106)
... 19 more
{code}
This looks to me like it was caused by [JBTM-1054]. I suspect there is an unexpected XML block present in jar:file:/tmp/jboss-as-7.1.1.Final/build/target/jboss-as-7.1.1.Final/modules/org/jboss/jts/main/jbossjts-4.16.3.Final.jar!/default-jbossts-properties.xml. For example one with a missing value. I've tried commenting out keys with empty values, but that didn't help. It's not clear to me from debugging the code, which element it is complaining about.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 6 months
[JBoss JIRA] (JBTM-1272) TxBridge tests install Arjuna jars into local maven repo which makes troubles when testing on Hudson
by Ivo Studensky (JIRA)
Ivo Studensky created JBTM-1272:
-----------------------------------
Summary: TxBridge tests install Arjuna jars into local maven repo which makes troubles when testing on Hudson
Key: JBTM-1272
URL: https://issues.jboss.org/browse/JBTM-1272
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Testing, TxBridge
Affects Versions: 4.16.5
Reporter: Ivo Studensky
Assignee: Ivo Studensky
Fix For: 4.16.6
The current txbridge tests install Arjuna jars which they depend on to the local maven repo in advance of the test run. This makes troubles on Hudson when more txbridge test jobs are running concurrently.
Remove the install step from build.xml and modify dependencies in pom.xml to use system scope and systemPath for Arjuna bits.
--
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, 6 months
[JBoss JIRA] (JBTM-1275) Unexpected Fault type returned when participant cannot complete
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1275:
-----------------------------------
Summary: Unexpected Fault type returned when participant cannot complete
Key: JBTM-1275
URL: https://issues.jboss.org/browse/JBTM-1275
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Critical
Fix For: 4.16.6, 4.17.1, 5.0.0.M2
Scenario:
* Client begins a BA
* Client invokes a service that enlists a participant
* Participant notifies the coordinator that it cannot complete
* Client asks the coordinator to close the BA
* The coordinator returns a Fault as the BA cannot be closed.
* The fault message appears to be a regular SOAP fault rather than a '{http://schemas.arjuna.com/ws/2005/10/wsarjtx}Fault' which causes the message to be dropped and the client hangs waiting for the response.
This is the stacktrace for the dropped message:
{code}
18:34:17,669 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http-/127.0.0.1:8080-3) Interceptor for {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationParticipantSer
vice#{http://schemas.arjuna.com/ws/2005/10/wsarjtx}FaultOperation has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Unexpected element {http://schemas.xmlsoa
p.org/soap/envelope/}Fault found. Expected {http://schemas.arjuna.com/ws/2005/10/wsarjtx}Fault.
at org.apache.cxf.interceptor.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:259) [cxf-rt-core-2.4.9.jar:2.4.9]
at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:201) [cxf-rt-core-2.4.9.jar:2.4.9]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) [cxf-api-2.4.9.jar:2.4.9]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-rt-core-2.4.9.jar:2.4.9]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207) [cxf-rt-transports-http-2.4.9.jar:2.4.9]
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185) [cxf-rt-transports-http-2.4.9.jar:2.4.9]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108) [cxf-rt-transports-http-2.4.9.jar:2.4.9]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
{code}
--
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, 6 months
[JBoss JIRA] (JBTM-1237) crashrecovery07 tests failing on Solaris11 x86/x86_64 platform
by Ivo Studensky (JIRA)
Ivo Studensky created JBTM-1237:
-----------------------------------
Summary: crashrecovery07 tests failing on Solaris11 x86/x86_64 platform
Key: JBTM-1237
URL: https://issues.jboss.org/browse/JBTM-1237
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Testing
Affects Versions: 4.6.1.CP13
Reporter: Ivo Studensky
Assignee: Tom Jenkinson
When running QA testsuite on Solaris 11 x86/x86_64 platform with Oracle JDK7 I hit intermittent failures at crashrecovery07 tests.
Affected tests:
CrashRecovery07_Test04
CrashRecovery07_Test05
CrashRecovery07_Test11
CrashRecovery07_Test12
output of Test05 (qa/results/113/task_0_out):
{noformat}
Sleeping for 180000ms.
Test will fail because we have just received value 2 for resource 0
Test will fail because we have just received value 2 for resource 1
Test has failed because we got 2 for 2
Failed
{noformat}
output of Test11 (qa/results/25/task_0_out):
{noformat}
Sleeping for 360000ms.
Test will fail because we have just received value 2 for resource 0
Test will fail because we have just received value 2 for resource 1
Test will fail because we have just received value 2 for resource 2
Test has failed because we got 2 for 3
Failed
{noformat}
Complete logs for the two issues detailed above can be found here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20TS/view/JBo...
output of Test04 (qa/results/92/task_0_out):
{noformat}
Sleeping for 450000ms.
Test will fail because we have just received value 2 for resource 0
Test has failed because we got 2 for 1
Failed
{noformat}
output of Test12 (qa/results/14/task_0_out):
{noformat}
Sleeping for 450000ms.
Test will fail because we have just received value 2 for resource 0
Test will fail because we have just received value 2 for resource 1
Test will fail because we have just received value 2 for resource 2
Test has failed because we got 2 for 3
Failed
{noformat}
Complete logs for Test04 and Test12 can be found here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20TS/view/JBo...
--
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, 6 months
[JBoss JIRA] (JBTM-1270) Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared
by jaikiran pai (JIRA)
jaikiran pai created JBTM-1270:
----------------------------------
Summary: Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared
Key: JBTM-1270
URL: https://issues.jboss.org/browse/JBTM-1270
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.16.4
Reporter: jaikiran pai
Assignee: Tom Jenkinson
A user has reported (with an example) that setting a transaction timeout on the UserTransaction will leak the timeout onto the thread and subsequent transaction creation on that thread uses the leaked value instead of new values. The com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction is using a ThreadLocal (_timeouts) for tracking timeouts but it is never cleared/reset.
More details in the referenced forum thread.
--
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-1271) Have Hudson comment on status of pull requests
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1271:
-----------------------------------
Summary: Have Hudson comment on status of pull requests
Key: JBTM-1271
URL: https://issues.jboss.org/browse/JBTM-1271
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Testing
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 4.17.1, 5.0.0.M2
Hudson should comment on the pull request when:
Test starts
A set of tests pass (e.g. XTS crash rec
When the job passes/fails
The following job is a PoC that I created: http://172.17.131.2/job/paul-test/configure
Here you will see that we have a jbosstm-bot user that creates the comment.
I think the code will need to go in narayana.sh as only it knows the progress of the tests.
--
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