[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1398:
-------------------------------------
Had a quick go at moving the TXF subsystem into the transactions subsytem: https://github.com/jbosstm/jboss-as/tree/TXF_in_transactions_subsystem
Problems:
* Cyclic dependency: Transactions -> Weld -> EJB3 -> Transactions
* Dependency on JBossWS subsystem
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 5 hours
> Remaining Estimate: 3 days
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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, 2 months
[JBoss JIRA] (JBTM-1340) BeanPopulator overhead needs looking into
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-1340:
-----------------------------------
Assignee: Tom Jenkinson (was: Michael Musgrove)
> BeanPopulator overhead needs looking into
> -----------------------------------------
>
> Key: JBTM-1340
> URL: https://issues.jboss.org/browse/JBTM-1340
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Common
> Affects Versions: 4.17.2
> Environment: Mac OS 10.7
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.Final
>
>
> During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit.
> 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.coordinator.TxStats.enabled
> 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean
> 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance
> 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance
> 2.5% - 1,587 ms - 10,000 inv. java.lang.StringBuilder.<init>
> 2.3% - 1,507 ms - 10,000 inv. java.lang.StringBuilder.toString
> 0.0% - 320 µs - 10,000 inv. java.util.concurrent.ConcurrentMap.containsKey
> 0.0% - 61 µs - 10,000 inv. java.lang.Class.getName
> 0.0% - 25 µs - 10,000 inv. java.util.concurrent.ConcurrentMap.get
--
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, 2 months
[JBoss JIRA] (JBTM-576) update unit tests
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-576?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson reassigned JBTM-576:
----------------------------------
Assignee: Gytis Trikleris (was: Michael Musgrove)
> update unit tests
> -----------------
>
> Key: JBTM-576
> URL: https://issues.jboss.org/browse/JBTM-576
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.7.0
> Reporter: Jonathan Halliday
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> There are many unit tests that have lain dormant for some time. Convert them from DTF/junit3 to junit4, wire them to the build and make them pass.
> This will be done incrementally, one module at a time, following the dependency chain e.g. common, ArjunaCore/arjuna, ArjunaCore/txoj, ... JTA/, .../JTS/...
--
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, 2 months
[JBoss JIRA] (JBTM-1293) ATBridgeTest#testSimple counter isn't incremented
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1293?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1293:
---------------------------------------
http://172.17.131.2/job/narayana/142
> ATBridgeTest#testSimple counter isn't incremented
> -------------------------------------------------
>
> Key: JBTM-1293
> URL: https://issues.jboss.org/browse/JBTM-1293
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 3 days
> Time Spent: 6 hours
> Remaining Estimate: 2 days, 2 hours
>
> See:
> http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-narayana-java7/21/...
> {code}
> @Test
> public void testSimple() throws Exception
> {
> ut.begin();
> client.incrementCounter(1);
> ut.commit();
> ut.begin();
> int counter = client.getCounter();
> ut.commit();
> Assert.assertEquals(1, counter);
> }
> {code}
> Even though the first transaction should have committed an update to the counter, it is still set to zero in the second transaction.
> This happens intermittently (once so far). It also happened on Beacon which is notorious for test failures caused by things going slowly. I would suspect that the bridged JTA transaction in the first transaction hasn't quite finished the commit when the second transaction is begun.
> If the WS-AT coordinator sends an async commit to the participants and an async committed to the client, then this problem could happen if the client's 'committed' is received before the participant's 'commit' message.
> To verify this we need to check that the coordinator sends an async (@OneWay) commit message to the participant. In which case the simplest solution is to add a 3sec delay between the two transactions. We should also look for other tests that may be affected.
--
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, 2 months
[JBoss JIRA] (JBTM-1420) org.apache.commons.io.output.DeferredFileOutputStream class not found
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1420?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1420:
---------------------------------------
http://172.17.131.2/job/narayana/142
> org.apache.commons.io.output.DeferredFileOutputStream class not found
> ---------------------------------------------------------------------
>
> Key: JBTM-1420
> URL: https://issues.jboss.org/browse/JBTM-1420
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, TXFramework
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.M2
>
>
> See: http://172.17.131.2/job/narayana/139
> {noformat}
> Tests in error:
> clientDrivenCommitTest(org.jboss.narayana.txframework.functional.rest.at.simpleEJB.ClientTXInterceptorTest): java.lang.NoClassDefFoundError: org/apache/commons/io/output/DeferredFileOutputStream
> multipleInvokeTest(org.jboss.narayana.txframework.functional.rest.at.simpleEJB.IndirectTXManagementTest): org/apache/commons/io/output/DeferredFileOutputStream
> clientDrivenRollbackTest(org.jboss.narayana.txframework.functional.rest.at.simpleEJB.IndirectTXManagementTest): org/apache/commons/io/output/DeferredFileOutputStream
> participantDrivenRollbackTest(org.jboss.narayana.txframework.functional.rest.at.simpleEJB.IndirectTXManagementTest): org/apache/commons/io/output/DeferredFileOutputStream
> clientDrivenCommitTest(org.jboss.narayana.txframework.functional.rest.at.simpleEJB.IndirectTXManagementTest): org/apache/commons/io/output/DeferredFileOutputStream
> {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, 2 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 edited comment on JBTM-986 at 1/11/13 4:30 AM:
-------------------------------------------------------------
The general approach I would take to implementing this feature would be:
* Read about JAX-WS features in the Spec
* Look at how MTOM et al are currently implemented in the client side soap stack provided by the JDK.
* Create a "Hello World" feature that just prints something to the console.
* Update the feature to add the XTS client-side handler to the client-side handler chain.
* Figure out how to have the feature enabled by default, so that the XTS client-side handler is added even if the developer doesn't specify the feature.
* Add some configuration to the XTS section of the standalone-xts.xml to have transaction context propagated by default.
was (Author: paul.robinson):
The general approach I would take to implementing this feature would be:
* Read about JAX-WS features in the Spec
* Look at how MTOM et al are currently implemented in CXF.
* Create a "Hello World" feature that just prints something to the console.
* Update the feature to add the XTS client-side handler to the client-side handler chain.
* Figure out how to have the feature enabled by default, so that the XTS client-side handler is added even if the developer doesn't specify the feature.
* Add some configuration to the XTS section of the standalone-xts.xml to have transaction context propagated by default.
> 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
> Priority: Minor
> Labels: assign
> Fix For: 5.0.0.M2
>
> Original Estimate: 4 days
> Time Spent: 1 day, 1 hour
> Remaining Estimate: 2 days, 7 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
13 years, 2 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Paul Robinson logged work on JBTM-1398:
---------------------------------------
Author: Paul Robinson
Created on: 11/Jan/13 4:27 AM
Start Date: 11/Jan/13 4:27 AM
Worklog Time Spent: 7 hours
Issue Time Tracking
-------------------
Remaining Estimate: 3 hours (was: 1 day, 2 hours)
Time Spent: 1 day, 5 hours (was: 6 hours)
Worklog Id: (was: 12428331)
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M2
>
> Original Estimate: 2 days
> Time Spent: 1 day, 5 hours
> Remaining Estimate: 3 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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, 2 months