[JBoss JIRA] (JBTM-1447) Create WebserviceFeature for TXBridge
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1447?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1447:
-------------------------------------
What happens if the Client is running in a JTA transaction, then begins a WS-BA transaction before calling a WS-BA enabled service? I suspect, as it stands, we would start a WS-AT transaction as well. This will cause the JaxBaseHeaderContextProcessor to default to WS-AT as it appears first in the if-then-elseif block:
{code}
final CoordinationContextType coordinationContext ;
if (atContext != null)
{
coordinationContext = atContext.getCoordinationContext() ;
}
else if (baContext != null)
{
coordinationContext = baContext.getCoordinationContext() ;
}
{code}
I'm not yet sure how we handle this case. We certainly need a test for it though.
> Create WebserviceFeature for TXBridge
> -------------------------------------
>
> Key: JBTM-1447
> URL: https://issues.jboss.org/browse/JBTM-1447
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TxBridge
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 hours
> Remaining Estimate: 1 day, 4 hours
>
> h2. Create:
> * JTAOverWSATFeature
> * Configuration option on the XTS Subsytem (defaultContextPropagation)
> h2. Semantics:
> h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
> This is the current OOTB experience for EAP 5&6. No handlers are activated automatically. The developer has to add them manually for all ports. When the developer does add the handlers, the MustUnderstand attribute of the WS-TX context is set to true.
> h4. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
> All Web service requests that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to false.
> h4. JTAOverWSATFeature enabled, defaultContextPropagation disabled
> All Web service requests, for this port, that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to true.
> h5. JTAOverWSATFeature disabled, defaultContextPropagation enabled
> All Web service requests, for this port, don't bridge JTA.
> h2. Implementation
> The XTS Subsystem reads its config on boot. It carries out one of the following actions depending on what it finds:
> # <defaultContextPropagation enabled=”true” /> (default OOTB config)
> Add the Bridge handler initialized to be enabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # <defaultContextPropagation enabled=”false” />
> Add the Bridge handler initialized to be disabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # Config absent.
> Error. Fail config parse.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.
> If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Backwards compatibility
> Existing applications (written before this feature was released) will be specifying Handler chains manually via the binding provider. Therefore we need to tolerate the situation where these handlers are added twice. Once for by this feature and again by the developer.
> In particular the handlers added by this feature and [JBTM-986] should do nothing if the com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor handler is already in the handler chain. We could achieve this by adding this handler in the post handler chain. We could then look for an existing WSTX header and do nothing if we find it. This is just a suggestion, there may be a better way to achieve this behaviour.
--
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
13 years, 1 month
[JBoss JIRA] (JBTM-1447) Create WebserviceFeature for TXBridge
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1447?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1447:
-------------------------------------
We should create a Jira issue to profile the overhead of bridging JTA to WS-AT, where the server side doesn't enlist any participants. This will happen when default propagation is enabled and the client is running a JTA. This is very common if the client is an EJB. The main issue is likely to be the additional disk sync for the unused WS-AT subordinate transaction.
We could probably detect the unused WS-AT transaction is a client response handler. We may then be able to de-list the WS-AT transaction or make it vote read-only. We need to investigate what imposes the lowest overhead.
> Create WebserviceFeature for TXBridge
> -------------------------------------
>
> Key: JBTM-1447
> URL: https://issues.jboss.org/browse/JBTM-1447
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TxBridge
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 hours
> Remaining Estimate: 1 day, 4 hours
>
> h2. Create:
> * JTAOverWSATFeature
> * Configuration option on the XTS Subsytem (defaultContextPropagation)
> h2. Semantics:
> h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
> This is the current OOTB experience for EAP 5&6. No handlers are activated automatically. The developer has to add them manually for all ports. When the developer does add the handlers, the MustUnderstand attribute of the WS-TX context is set to true.
> h4. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
> All Web service requests that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to false.
> h4. JTAOverWSATFeature enabled, defaultContextPropagation disabled
> All Web service requests, for this port, that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to true.
> h5. JTAOverWSATFeature disabled, defaultContextPropagation enabled
> All Web service requests, for this port, don't bridge JTA.
> h2. Implementation
> The XTS Subsystem reads its config on boot. It carries out one of the following actions depending on what it finds:
> # <defaultContextPropagation enabled=”true” /> (default OOTB config)
> Add the Bridge handler initialized to be enabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # <defaultContextPropagation enabled=”false” />
> Add the Bridge handler initialized to be disabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # Config absent.
> Error. Fail config parse.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.
> If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Backwards compatibility
> Existing applications (written before this feature was released) will be specifying Handler chains manually via the binding provider. Therefore we need to tolerate the situation where these handlers are added twice. Once for by this feature and again by the developer.
> In particular the handlers added by this feature and [JBTM-986] should do nothing if the com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor handler is already in the handler chain. We could achieve this by adding this handler in the post handler chain. We could then look for an existing WSTX header and do nothing if we find it. This is just a suggestion, there may be a better way to achieve this behaviour.
--
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
13 years, 1 month
[JBoss JIRA] (JBTM-1447) Create WebserviceFeature for TXBridge
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1447?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1447:
--------------------------------
Description:
h2. Create:
* JTAOverWSATFeature
* Configuration option on the XTS Subsytem (defaultContextPropagation)
h2. Semantics:
h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
This is the current OOTB experience for EAP 5&6. No handlers are activated automatically. The developer has to add them manually for all ports. When the developer does add the handlers, the MustUnderstand attribute of the WS-TX context is set to true.
h4. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
All Web service requests that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to false.
h4. JTAOverWSATFeature enabled, defaultContextPropagation disabled
All Web service requests, for this port, that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to true.
h5. JTAOverWSATFeature disabled, defaultContextPropagation enabled
All Web service requests, for this port, don't bridge JTA.
h2. Implementation
The XTS Subsystem reads its config on boot. It carries out one of the following actions depending on what it finds:
# <defaultContextPropagation enabled=”true” /> (default OOTB config)
Add the Bridge handler initialized to be enabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
# <defaultContextPropagation enabled=”false” />
Add the Bridge handler initialized to be disabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
# Config absent.
Error. Fail config parse.
h5. Bridge handler
Two handlers that delegate to the existing TXBridge handler:
# Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
# Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.
If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
h5. Backwards compatibility
Existing applications (written before this feature was released) will be specifying Handler chains manually via the binding provider. Therefore we need to tolerate the situation where these handlers are added twice. Once for by this feature and again by the developer.
In particular the handlers added by this feature and [JBTM-986] should do nothing if the com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor handler is already in the handler chain. We could achieve this by adding this handler in the post handler chain. We could then look for an existing WSTX header and do nothing if we find it. This is just a suggestion, there may be a better way to achieve this behaviour.
was:
h2. Create:
* JTAOverWSATFeature
* Configuration option on the XTS Subsytem (defaultContextPropagation)
h2. Semantics:
h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
This is the current OOTB experience for EAP 5&6. No handlers are activated automatically. The developer has to add them manually for all ports.
h4. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
All Web service requests that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header.
h4. JTAOverWSATFeature enabled, defaultContextPropagation disabled
All Web service requests, for this port, that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header.
h5. JTAOverWSATFeature disabled, defaultContextPropagation enabled
All Web service requests, for this port, don't bridge JTA.
h2. Implementation
The XTS Subsystem reads its config on boot. It carries out one of the following actions depending on what it finds:
# <defaultContextPropagation enabled=”true” /> (default OOTB config)
Add the Bridge handler initialized to be enabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
# <defaultContextPropagation enabled=”false” />
Add the Bridge handler initialized to be disabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
# Config absent.
Error. Fail config parse.
h5. Bridge handler
Two handlers that delegate to the existing TXBridge handler:
# Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
# Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.
If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> Create WebserviceFeature for TXBridge
> -------------------------------------
>
> Key: JBTM-1447
> URL: https://issues.jboss.org/browse/JBTM-1447
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TxBridge
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 hours
> Remaining Estimate: 1 day, 4 hours
>
> h2. Create:
> * JTAOverWSATFeature
> * Configuration option on the XTS Subsytem (defaultContextPropagation)
> h2. Semantics:
> h4. JTAOverWSATFeature absent, defaultContextPropagation disabled
> This is the current OOTB experience for EAP 5&6. No handlers are activated automatically. The developer has to add them manually for all ports. When the developer does add the handlers, the MustUnderstand attribute of the WS-TX context is set to true.
> h4. JTAOverWSATFeature absent, defaultContextPropagation enabled (Default OOTB)
> All Web service requests that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to false.
> h4. JTAOverWSATFeature enabled, defaultContextPropagation disabled
> All Web service requests, for this port, that are made in the context of a JTA transaction will be bridged to WS-AT and the WS-AT context added to the request soap header. MustUnderstand is set to true.
> h5. JTAOverWSATFeature disabled, defaultContextPropagation enabled
> All Web service requests, for this port, don't bridge JTA.
> h2. Implementation
> The XTS Subsystem reads its config on boot. It carries out one of the following actions depending on what it finds:
> # <defaultContextPropagation enabled=”true” /> (default OOTB config)
> Add the Bridge handler initialized to be enabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # <defaultContextPropagation enabled=”false” />
> Add the Bridge handler initialized to be disabled by default then do [JBTM-986] after. Ensure that the Bridge handler is invoked before the WSTX handler.
> # Config absent.
> Error. Fail config parse.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAOverWSATFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAOverWSATFeature is present and disabled.
> If the bridge detects the JTAOverWSATFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAOverWSATFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Backwards compatibility
> Existing applications (written before this feature was released) will be specifying Handler chains manually via the binding provider. Therefore we need to tolerate the situation where these handlers are added twice. Once for by this feature and again by the developer.
> In particular the handlers added by this feature and [JBTM-986] should do nothing if the com.arjuna.mw.wst11.client.JaxWSHeaderContextProcessor handler is already in the handler chain. We could achieve this by adding this handler in the post handler chain. We could then look for an existing WSTX header and do nothing if we find it. This is just a suggestion, there may be a better way to achieve this behaviour.
--
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
13 years, 1 month
[JBoss JIRA] (JBTM-1484) IndirectTXManagementTest failed after TXDataMap class was not found
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1484?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris closed JBTM-1484.
---------------------------------
Resolution: Rejected
> IndirectTXManagementTest failed after TXDataMap class was not found
> -------------------------------------------------------------------
>
> Key: JBTM-1484
> URL: https://issues.jboss.org/browse/JBTM-1484
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Demonstrator, TXFramework
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M2
>
>
> See: http://172.17.131.2/job/btny-narayana-quickstarts-taconic/238
> {noformat}
> Running org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 27.313 sec <<< FAILURE!
> Results :
> Tests in error:
> org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest: Cannot deploy: test.war
> {noformat}
> {noformat}
> 16:18:06,448 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."test.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "test.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.3.GA.jar:1.0.3.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.3.GA.jar:1.0.3.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.jboss.narayana.quickstarts.restat.taxi.TaxiServiceATImpl with ClassLoader ModuleClassLoader for Module "deployment.test.war:main" from Service Module Loader
> at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:72) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:107)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:92)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 5 more
> Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/narayana/txframework/api/management/TXDataMap;
> at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_31]
> at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_31]
> at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_31]
> at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:68) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 10 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.txframework.api.management.TXDataMap from [Module "deployment.test.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
> ... 15 more
> 16:18:06,459 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "test.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment \"test.war\"
> Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.jboss.narayana.quickstarts.restat.taxi.TaxiServiceATImpl with ClassLoader ModuleClassLoader for Module \"deployment.test.war:main\" from Service Module Loader
> Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/narayana/txframework/api/management/TXDataMap;
> Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.txframework.api.management.TXDataMap from [Module \"deployment.test.war:main\" from Service Module Loader]"}}
> {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
13 years, 1 month
[JBoss JIRA] (JBTM-1484) IndirectTXManagementTest failed after TXDataMap class was not found
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1484?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1484:
---------------------------------------
Sorry about this, I was already creating this JIRA when comment on the failed build was added
> IndirectTXManagementTest failed after TXDataMap class was not found
> -------------------------------------------------------------------
>
> Key: JBTM-1484
> URL: https://issues.jboss.org/browse/JBTM-1484
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Demonstrator, TXFramework
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M2
>
>
> See: http://172.17.131.2/job/btny-narayana-quickstarts-taconic/238
> {noformat}
> Running org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 27.313 sec <<< FAILURE!
> Results :
> Tests in error:
> org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest: Cannot deploy: test.war
> {noformat}
> {noformat}
> 16:18:06,448 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."test.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "test.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.3.GA.jar:1.0.3.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.3.GA.jar:1.0.3.GA]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.jboss.narayana.quickstarts.restat.taxi.TaxiServiceATImpl with ClassLoader ModuleClassLoader for Module "deployment.test.war:main" from Service Module Loader
> at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:72) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:107)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:92)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 5 more
> Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/narayana/txframework/api/management/TXDataMap;
> at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_31]
> at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_31]
> at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_31]
> at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:68) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 10 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.txframework.api.management.TXDataMap from [Module "deployment.test.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
> ... 15 more
> 16:18:06,459 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "test.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment \"test.war\"
> Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.jboss.narayana.quickstarts.restat.taxi.TaxiServiceATImpl with ClassLoader ModuleClassLoader for Module \"deployment.test.war:main\" from Service Module Loader
> Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/narayana/txframework/api/management/TXDataMap;
> Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.txframework.api.management.TXDataMap from [Module \"deployment.test.war:main\" from Service Module Loader]"}}
> {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
13 years, 1 month
[JBoss JIRA] (JBTM-1484) IndirectTXManagementTest failed after TXDataMap class was not found
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-1484:
-------------------------------------
Summary: IndirectTXManagementTest failed after TXDataMap class was not found
Key: JBTM-1484
URL: https://issues.jboss.org/browse/JBTM-1484
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Demonstrator, TXFramework
Reporter: Gytis Trikleris
Assignee: Paul Robinson
Priority: Minor
Fix For: 5.0.0.M2
See: http://172.17.131.2/job/btny-narayana-quickstarts-taconic/238
{noformat}
Running org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 27.313 sec <<< FAILURE!
Results :
Tests in error:
org.jboss.narayana.quickstarts.restat.IndirectTXManagementTest: Cannot deploy: test.war
{noformat}
{noformat}
16:18:06,448 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."test.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "test.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.3.GA.jar:1.0.3.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.3.GA.jar:1.0.3.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.jboss.narayana.quickstarts.restat.taxi.TaxiServiceATImpl with ClassLoader ModuleClassLoader for Module "deployment.test.war:main" from Service Module Loader
at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:72) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:107)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:92)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 5 more
Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/narayana/txframework/api/management/TXDataMap;
at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_31]
at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_31]
at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_31]
at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:68) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
... 10 more
Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.txframework.api.management.TXDataMap from [Module "deployment.test.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
... 15 more
16:18:06,459 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "test.war" was rolled back with the following failure message:
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment \"test.war\"
Caused by: java.lang.RuntimeException: JBAS018757: Error getting reflective information for class org.jboss.narayana.quickstarts.restat.taxi.TaxiServiceATImpl with ClassLoader ModuleClassLoader for Module \"deployment.test.war:main\" from Service Module Loader
Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/narayana/txframework/api/management/TXDataMap;
Caused by: java.lang.ClassNotFoundException: org.jboss.narayana.txframework.api.management.TXDataMap from [Module \"deployment.test.war:main\" from Service Module Loader]"}}
{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
13 years, 1 month
[JBoss JIRA] (JBTM-1237) qa timeout MFACTOR (was: crashrecovery07 tests failing on Solaris11 x86/x86_64 platform)
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-1237?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka edited comment on JBTM-1237 at 2/21/13 3:50 PM:
-----------------------------------------------------------------
During the test cycle of EAP 5.2.0 I haven't hit this problem. I suppose that this jira is solved. In case of problems I would reopen it.
You can check runs here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbossts-testsuite-so...
was (Author: ochaloup):
During the test cycle of EAP 5.2.0 I've not hit this problem. I suppose that this jira is solved. In case of problems I would reopen it.
You can check runs here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbossts-testsuite-so...
> qa timeout MFACTOR (was: 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: Ondřej Chaloupka
> Fix For: 4.6.1.CP14
>
>
> 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
13 years, 1 month