[JBoss JIRA] (JBTM-1476) Document new XTS Features
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1476:
-----------------------------------
Summary: Document new XTS Features
Key: JBTM-1476
URL: https://issues.jboss.org/browse/JBTM-1476
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
Fix For: 5.0.0.Final
Plan for new XTS features and docs:
# Implement new feature
# Release a milestone of 5.0.0
# Publish a blog post shortly after release
# Refine the feature based on community feedback
# Document the feature in the XTS xts_administration_and_development_guide before the 5.0.0.Final release (this issue is to do this item)
Here's a list of features that need documenting, so far:
JBTM-986 Automatically setup the client side handler chain
JBTM-1447 Create WebserviceFeature for TXBridge
--
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:
--------------------------------
Assignee: Gytis Trikleris (was: Paul Robinson)
> 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.
> 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.
--
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.
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.
was:
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.
> 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:
> * 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.
--
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:
--------------------------------
Priority: Major (was: Minor)
> 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
13 years, 1 month
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1147:
--------------------------------
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M2)
> Refactor ParticipantCompletion recovery tests to remove duplicate rules
> -----------------------------------------------------------------------
>
> Key: JBTM-1147
> URL: https://issues.jboss.org/browse/JBTM-1147
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Ondřej Chaloupka
> Priority: Minor
> Fix For: 5.0.0.M3
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
> The following rules in BACrashDuringCommit could be refactored into a single rule
> {code}
> #####################################################################
> # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> These can be re-factored in to a rule like this:
> {code}
> RULE setup counter
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT ENTRY
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> This assumes that we have the same numbers for each use of:
> {code}
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> {code}
> Which is *usually* the case:
> {code}
> grep -r createCounter\(\"closes\" .
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> {code}
> Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
> Also, the following similar rules are also present in this file:
> {code}
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> Which could be replaced with something like this:
> {code}
> RULE wait for closes
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
--
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-1016) Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1016?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1016:
--------------------------------
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M2)
> Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1016
> URL: https://issues.jboss.org/browse/JBTM-1016
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Labels: assign
> Fix For: 5.0.0.M3
>
>
> I've found many bugs in the XTS crash recovery tests that where due to changes being made to the XTS code without updating the byteman scripts. The problem is that these inconsistencies often go unnoticed when the tests run, until you notice a failure in the test.
> Can we run bmcheck as part of the maven build and make the build fail if it detects errors? Needs to be integrated into the poms, perhaps by an exec in an antrun plugin
> NOTE: Before raising the pull req it will be necessary to resolve any the discovered errors.
--
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-1460) TXBridge test hangs when Arquillian starts the container
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1460?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1460:
--------------------------------
Fix Version/s: 5.0.0.M3
(was: 5.0.0.M2)
> TXBridge test hangs when Arquillian starts the container
> --------------------------------------------------------
>
> Key: JBTM-1460
> URL: https://issues.jboss.org/browse/JBTM-1460
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: AS7 master as of 2013-02-05
> Arquillian core: 1.0.0.Final
> Arquillian osgi: 1.0.2.Final
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M3
>
> Attachments: client.log, server.log
>
>
> See: 172.17.131.2/job/btny-pulls-narayana/345/ where the job has hung for about 16hrs.
> From looking at the stack trace in client.log (attached):
> {code}
> at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:107)
> at org.jboss.jbossts.txbridge.tests.inbound.junit.InboundBasicTests.setUp(InboundBasicTests.java:75)
> {code}
> The hang is happening on this line:
> {code}
> controller.start(CONTAINER);
> {code}
> Which is starting the container 'jboss', which is described in the arquillian.xml as:
> {code}
> <container qualifier="jboss" default="true" mode="manual">
> <configuration>
> <property name="javaVmArguments">${server.jvm.args}</property>
> <property name="serverConfig">standalone-xts.xml</property>
> <property name="managementAddress">${node.address}</property>
> </configuration>
> </container>
> {code}
> From looking at server.log (attached) it looks like the server has started and deployed the deployments:
> First of two deployments:
> {code}
> 18:36:32,013 INFO [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "txbridge-inbound-tests-service.war" (runtime-name : "txbridge-inbound-tests-service.war")
> {code}
> Second of two deployments:
> {code}
> 18:36:32,975 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "txbridge-inbound-tests-client.war" (runtime-name : "txbridge-inbound-tests-client.war")
> {code}
> Notice that the output above is that last line of output on the server.
--
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