[JBoss JIRA] (JBTM-941) Fix intermittant qa suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-941?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-941:
-------------------------------
Issue Type: Bug (was: Task)
> Fix intermittant qa suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote
> -------------------------------------------------------------------------------------------
>
> Key: JBTM-941
> URL: https://issues.jboss.org/browse/JBTM-941
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 4.16.4, 4.17.0
>
> Attachments: jtsremote.tgz
>
>
> Assuming failure in test, rather than failed test
> I have saved a build with the error:
> http://albany/view/Narayana+BlackTie/job/narayana-java6/1159/
> The logs are browseable:
> http://albany/view/Narayana+BlackTie/job/narayana-java6/1159/artifact/qa/...
> http://albany/view/Narayana+BlackTie/job/narayana-java6/1159/artifact/qa/...
> For some reason the client gets a timeout:
> http://albany/view/Narayana+BlackTie/job/narayana-java6/1159/artifact/qa/...
> 2012-04-12 16:00:00,662 err: object is deactivated
> 2012-04-12 16:01:00,003 out: 2012-04-12 16:01:00,003 [Transaction Reaper] WARN com.arjuna.ats.arjuna - ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac118314:be94:4f86edc3:a11 in state RUN
> 2012-04-12 16:01:00,005 err: 2012-04-12 16:01:00.005 FINE trying is_a remotely
> 2012-04-12 16:01:00,005 out: 2012-04-12 16:01:00,004 [Transaction Reaper Worker 0] WARN com.arjuna.ats.arjuna - ARJUNA012095: Abort of action id 0:ffffac118314:be94:4f86edc3:a11 invoked while multiple threads active within it.
> 2012-04-12 16:01:00,005 out: 2012-04-12 16:01:00,004 [Transaction Reaper Worker 0] WARN com.arjuna.ats.arjuna - ARJUNA012108: CheckedAction::check - atomic action 0:ffffac118314:be94:4f86edc3:a11 aborting with 1 threads active!
> 2012-04-12 16:01:00,005 out: 2012-04-12 16:01:00,004 [Transaction Reaper Worker 0] WARN com.arjuna.ats.arjuna - ARJUNA012098: Abort of action id 0:ffffac118314:be94:4f86edc3:a11 invoked while child actions active
> 2012-04-12 16:01:00,005 out: 2012-04-12 16:01:00,004 [Transaction Reaper Worker 0] WARN com.arjuna.ats.arjuna - ARJUNA012099: Aborting child: 0:ffffac118314:be94:4f86edc3:a33
> 2012-04-12 16:01:00,005 out: 2012-04-12 16:01:00,004 [Transaction Reaper Worker 0] WARN com.arjuna.ats.arjuna - ARJUNA012095: Abort of action id 0:ffffac118314:be94:4f86edc3:a33 invoked while multiple threads active within it.
> 2012-04-12 16:01:00,005 out: 2012-04-12 16:01:00,004 [Transaction Reaper Worker 0] WARN com.arjuna.ats.arjuna - ARJUNA012108: CheckedAction::check - atomic action 0:ffffac118314:be94:4f86edc3:a33 aborting with 1 threads active!
> After that the test goes a bit strange and has a 6 minute pause:
> 2012-04-12 16:01:00,515 err: object is deactivated
> 2012-04-12 16:07:13,782 err: 2012-04-12 16:07:13.782 FINE Transport to 172.17.131.20:39996: stream closed on read < 0
--
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, 3 months
[JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s... ]
Paul Robinson commented on JBTM-986:
------------------------------------
This is what, I think, we should do if no WS-TX transaction present:
* WSTXFeature enabled. Throw an Exception as the developer has explicitly stated that they wish to propagate transaction context for this port.
* WSTXFeature absent, server configured to propagate by default. log to trace and do nothing.
> Automatically setup the client side handler chain
> -------------------------------------------------
>
> Key: JBTM-986
> URL: https://issues.jboss.org/browse/JBTM-986
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Labels: assign
> Fix For: 5.0.0.M2
>
> Original Estimate: 4 days
> Time Spent: 1 week, 2 hours
> Remaining Estimate: 2 hours
>
> When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the client stub to manage transaction context propagation. The code required to do this is as follows:
> {code}
> BindingProvider bindingProvider = (BindingProvider) client;
> List<Handler> handlers = new ArrayList<Handler>(1);
> handlers.add(new JaxWSHeaderContextProcessor());
> bindingProvider.getBinding().setHandlerChain(handlers);
> {code}
> This is not very user friendly.
> This could be done using a JAX-WS feature passed to the Client-side port.
> We also need to support client stubs created using @WebServiceRef. Here's some examples of its use:
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
> The feature should be "enabled" by default providing the feature is enabled in the XTS server config.
> The quickstarts also need updated to use this.
--
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, 3 months
[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 logged work on JBTM-1447:
---------------------------------------
Author: Paul Robinson
Edited by: Paul Robinson
Created on: 11/Feb/13 9:20 AM
Edited on: 11/Feb/13 9:21 AM
Start Date: 11/Feb/13 9:19 AM
Worklog Time Spent: 2 hours (was: 1 day)
Work Description: We also need to test every scenario. Hopefully we can use the same pattern as [JBTM-986].
Issue Time Tracking
-------------------
Remaining Estimate: 1 day, 4 hours (was: 2 days)
Time Spent: 2 hours (was: 1 day)
Worklog Id: (was: 12428696)
> 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: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 hours
> Remaining Estimate: 1 day, 4 hours
>
> h2. Create:
> * JTAtoWSTXFeature
> * Configuration option on the XTS Subsytem. Lets call it "ByDefaultBridgeFromJTA" for now, subject to change.
> h2. Semantics:
> h4. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA absent (Default OOTB)
> 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. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA present
> 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. JTAtoWSTXFeature enabled, ByDefaultBridgeFromJTA absent
> 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. JTAtoWSTXFeature disabled, ByDefaultBridgeFromJTA present
> 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:
> # <propagateByDefault/> or <propagateByDefault bridgeJTAByDefault='false'/>
> Just do [JBTM-986].
> # <propagateByDefault bridgeJTAByDefault='true'/>
> 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.
> # No propagateByDefault Element
> Config absent. 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.
> 'bridgeJTAByDefault' is an attribute of 'propagateByDefault' as 'bridgeJTAByDefault' depends on 'propagateByDefault' being present.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAtoWSTXFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAtoWSTXFeature is present and disabled.
> If the bridge detects the JTAtoWSTXFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAtoWSTXFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Existing handler changes
> We may need to change the TXBridge handler to tolerate the scenario where no JTA transaction is present. Fail silently if JTAtoWSTXFeature missing, but throw an Exception if JTAtoWSTXFeature is set. It is assumed that if the port has JTAtoWSTXFeature enabled, there should be a JTA transaction in place. This matches the the current semantics: if the developer adds the TXBridge handler, throw an Exception if no JTA present. This also allows the developer to add a sanity check (set the JTAtoWSTXFeature) to make sure that the call is only ever called in the context of a JTA transaction.
--
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, 3 months
[JBoss JIRA] (JBTM-1447) Create WebserviceFeature for TXBridge
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1447?focusedWorklogId=12428696&page=... ]
Paul Robinson logged work on JBTM-1447:
---------------------------------------
Author: Paul Robinson
Created on: 11/Feb/13 9:20 AM
Start Date: 11/Feb/13 9:19 AM
Worklog Time Spent: 1 day
Work Description: We also need to test every scenario. Hopefully we can use the same pattern as [JBTM-986].
Issue Time Tracking
-------------------
Remaining Estimate: 2 days (was: 1 day)
Time Spent: 1 day
Worklog Id: (was: 12428696)
> 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: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 1 day
> Remaining Estimate: 2 days
>
> h2. Create:
> * JTAtoWSTXFeature
> * Configuration option on the XTS Subsytem. Lets call it "ByDefaultBridgeFromJTA" for now, subject to change.
> h2. Semantics:
> h4. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA absent (Default OOTB)
> 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. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA present
> 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. JTAtoWSTXFeature enabled, ByDefaultBridgeFromJTA absent
> 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. JTAtoWSTXFeature disabled, ByDefaultBridgeFromJTA present
> 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:
> # <propagateByDefault/> or <propagateByDefault bridgeJTAByDefault='false'/>
> Just do [JBTM-986].
> # <propagateByDefault bridgeJTAByDefault='true'/>
> 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.
> # No propagateByDefault Element
> Config absent. 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.
> 'bridgeJTAByDefault' is an attribute of 'propagateByDefault' as 'bridgeJTAByDefault' depends on 'propagateByDefault' being present.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAtoWSTXFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAtoWSTXFeature is present and disabled.
> If the bridge detects the JTAtoWSTXFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAtoWSTXFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Existing handler changes
> We may need to change the TXBridge handler to tolerate the scenario where no JTA transaction is present. Fail silently if JTAtoWSTXFeature missing, but throw an Exception if JTAtoWSTXFeature is set. It is assumed that if the port has JTAtoWSTXFeature enabled, there should be a JTA transaction in place. This matches the the current semantics: if the developer adds the TXBridge handler, throw an Exception if no JTA present. This also allows the developer to add a sanity check (set the JTAtoWSTXFeature) to make sure that the call is only ever called in the context of a JTA transaction.
--
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, 3 months
[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:
* JTAtoWSTXFeature
* Configuration option on the XTS Subsytem. Lets call it "ByDefaultBridgeFromJTA" for now, subject to change.
h2. Semantics:
h4. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA absent (Default OOTB)
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. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA present
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. JTAtoWSTXFeature enabled, ByDefaultBridgeFromJTA absent
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. JTAtoWSTXFeature disabled, ByDefaultBridgeFromJTA present
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:
# <propagateByDefault/> or <propagateByDefault bridgeJTAByDefault='false'/>
Just do [JBTM-986].
# <propagateByDefault bridgeJTAByDefault='true'/>
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.
# No propagateByDefault Element
Config absent. 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.
'bridgeJTAByDefault' is an attribute of 'propagateByDefault' as 'bridgeJTAByDefault' depends on 'propagateByDefault' being present.
h5. Bridge handler
Two handlers that delegate to the existing TXBridge handler:
# Disabled by default. Only invokes the TXBridge handler if the JTAtoWSTXFeature is present and enabled.
# Enabled by default. Always invokes the TXBridge handler unless the JTAtoWSTXFeature is present and disabled.
If the bridge detects the JTAtoWSTXFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAtoWSTXFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
h5. Existing handler changes
We may need to change the TXBridge handler to tolerate the scenario where no JTA transaction is present. Fail silently if JTAtoWSTXFeature missing, but throw an Exception if JTAtoWSTXFeature is set. It is assumed that if the port has JTAtoWSTXFeature enabled, there should be a JTA transaction in place. This matches the the current semantics: if the developer adds the TXBridge handler, throw an Exception if no JTA present. This also allows the developer to add a sanity check (set the JTAtoWSTXFeature) to make sure that the call is only ever called in the context of a JTA transaction.
was:Details to follow...
> 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: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> h2. Create:
> * JTAtoWSTXFeature
> * Configuration option on the XTS Subsytem. Lets call it "ByDefaultBridgeFromJTA" for now, subject to change.
> h2. Semantics:
> h4. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA absent (Default OOTB)
> 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. JTAtoWSTXFeature absent, ByDefaultBridgeFromJTA present
> 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. JTAtoWSTXFeature enabled, ByDefaultBridgeFromJTA absent
> 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. JTAtoWSTXFeature disabled, ByDefaultBridgeFromJTA present
> 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:
> # <propagateByDefault/> or <propagateByDefault bridgeJTAByDefault='false'/>
> Just do [JBTM-986].
> # <propagateByDefault bridgeJTAByDefault='true'/>
> 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.
> # No propagateByDefault Element
> Config absent. 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.
> 'bridgeJTAByDefault' is an attribute of 'propagateByDefault' as 'bridgeJTAByDefault' depends on 'propagateByDefault' being present.
> h5. Bridge handler
> Two handlers that delegate to the existing TXBridge handler:
> # Disabled by default. Only invokes the TXBridge handler if the JTAtoWSTXFeature is present and enabled.
> # Enabled by default. Always invokes the TXBridge handler unless the JTAtoWSTXFeature is present and disabled.
> If the bridge detects the JTAtoWSTXFeature, but no WSTXFeature, it adds the WSTXFeature to the invocation context (setting WSTXFeature.enabled = JTAtoWSTXFeature.enabled). This is needed by the WSTX handler and prevents the developer from having to add both.
> h5. Existing handler changes
> We may need to change the TXBridge handler to tolerate the scenario where no JTA transaction is present. Fail silently if JTAtoWSTXFeature missing, but throw an Exception if JTAtoWSTXFeature is set. It is assumed that if the port has JTAtoWSTXFeature enabled, there should be a JTA transaction in place. This matches the the current semantics: if the developer adds the TXBridge handler, throw an Exception if no JTA present. This also allows the developer to add a sanity check (set the JTAtoWSTXFeature) to make sure that the call is only ever called in the context of a JTA transaction.
--
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, 3 months
[JBoss JIRA] (JBTM-1462) Create a script to rebase 5_branch and 4_branch against AS7 master
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1462?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1462:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Create a script to rebase 5_branch and 4_branch against AS7 master
> ------------------------------------------------------------------
>
> Key: JBTM-1462
> URL: https://issues.jboss.org/browse/JBTM-1462
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 hours
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Rebasing against AS7 master needs to be done regularly, especially when you are making a change that is dependent on a new commit from upstream.
> Doing the rebase is dangerous as it needs a -f. By scripting this, we can hopefully make the operation safer. This is providing the script is reviewed carefully.
> We may also want the script to take a backup of 5_branch prior to the forced update, so that any error can be easily reverted.
--
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, 3 months