[JBoss JIRA] (JBTM-1447) Create WebserviceFeature for TXBridge
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1447?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris closed JBTM-1447.
---------------------------------
> 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 days, 2 hours
> Remaining Estimate: 0 minutes
>
> 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
11 years, 2 months
[JBoss JIRA] (JBTM-1424) Remove static block from org.jboss.jbossts.xts.environment.XTSPropertyManager
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1424?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1424:
--------------------------------
Issue Type: Task (was: Enhancement)
> Remove static block from org.jboss.jbossts.xts.environment.XTSPropertyManager
> -----------------------------------------------------------------------------
>
> Key: JBTM-1424
> URL: https://issues.jboss.org/browse/JBTM-1424
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
> Original Estimate: 10 minutes
> Time Spent: 10 minutes
> Remaining Estimate: 0 minutes
>
> Where it catches an exception in the static block and then just uses system properties. I would say that behavior would be better encapsulated in XTSPropertiesFactory.getDefaultProperties itself (thereby removing another static block and making XTSPropertiesFactory.getDefaultProperties more stable).
--
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, 2 months
[JBoss JIRA] (JBTM-1852) Rollback local participant and remove log entry if transaction is not active during recovery.
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1852?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris closed JBTM-1852.
---------------------------------
> Rollback local participant and remove log entry if transaction is not active during recovery.
> ---------------------------------------------------------------------------------------------
>
> Key: JBTM-1852
> URL: https://issues.jboss.org/browse/JBTM-1852
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: REST
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M5
>
> Original Estimate: 30 minutes
> Time Spent: 2 hours, 45 minutes
> Remaining Estimate: 0 minutes
>
> Recovery is not working properly in REST-AT multiplexor. Problem happens if both coordinator and participant crashes straight after the participant is prepared but before the coordinator gets the vote. After both parties are recovered, coordinator does not know about the transaction. Therefore, participant has to be rolled back. However, multiplexor keeps participant active.
--
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, 2 months
[JBoss JIRA] (JBTM-1879) JdbcObjectStore is not closing connection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1879?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1879:
--------------------------------
Issue Type: Bug (was: Feature Request)
> JdbcObjectStore is not closing connection
> -----------------------------------------
>
> Key: JBTM-1879
> URL: https://issues.jboss.org/browse/JBTM-1879
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 4.17.8, 5.0.0.M5
>
>
> maeste: it looks like a bug on our side, can you raise a Jira for us please (maybe with your stack trace)?
> <tomjenkinson> maeste: thanks for fixing WFLY-1460 :)
> <jbossbot> jira [WFLY-1460] WildFly server fails to start with transactions configured to be run with JDBCObject store [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/WFLY-1460
> <tomjenkinson> maeste: it looks like the same thread is not used more than once?
> <tomjenkinson> maeste: the connection was being held on the thread you see
> <tomjenkinson> maeste: I assume that new threads are created constantly and not recycled now in WildFly?
> <maeste> tomjenkinson: yup should be
> <tomjenkinson> maeste: if there was a thread pool you would not have seen this
> <maeste> tomjenkinson: hmmm is on shotdown
> <maeste> tomjenkinson: on thread pool removing so
> <maeste> tomjenkinson: BTW I've just configure jdbcstore No operation executed, and so I suppose no write on DB, and I get this stacktrace when I shutdown WildFly
> <tomjenkinson> maeste: we can close the connections more timely it is ok, I don't know what the performance impact of connection.close with each object store update though
> <tomjenkinson> maeste: when you say "this stacktrace" you mean the gist you pasted before?
> <maeste> tomjenkinson: can't you close connection on shutdown? Well I'm fine to call a new convenient method on service shutdown if it's doable
> <maeste> tomjenkinson: yup
> <tomjenkinson> maeste: we are allocating one connection per thread
> * clebert (~clebert@redhat/jboss/clebert) has joined #jbossts
> <tomjenkinson> maeste: would shutdown be called on the transaction manager before LeakConnectionDetecter is triggered?
> <tomjenkinson> maeste: if so that sounds like the best idea
> <maeste> tomjenkinson: yup
> * Jaikiran (~jaikiran@redhat/jboss/Jaikiran) has joined #jbossts
> <tomjenkinson> maeste: ok, so we can do that, we can store the references that each thread creates in a global map too, then in shutdown close them all
> <tomjenkinson> maeste: then hook that into the transaction subsystem
> Stack trace
> 16:40:23,273 ERROR [org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool] (MSC service thread 1-2) IJ000616: Leak detected in pool: ExampleDS: java.lang.Throwable: ALLOCATION LEAK
> at org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool.getConnection(LeakDumperManagedConnectionPool.java:90) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:452) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:420) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:379) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:352) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:513) [ironjacamar-core-impl-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:142) [ironjacamar-jdbc-1.1.0.Final.jar:1.1.0.Final]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DataSourceJDBCAccess.getConnection(DataSourceJDBCAccess.java:50) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver$1.initialValue(JDBCImple_driver.java:632) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver$1.initialValue(JDBCImple_driver.java:627) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:160) [rt.jar:1.7.0_09-icedtea]
> at java.lang.ThreadLocal.get(ThreadLocal.java:150) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCImple_driver.initialise(JDBCImple_driver.java:639) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore.<init>(JDBCStore.java:267) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09-icedtea]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:131) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:165) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.setupStore(StoreManager.java:136) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.objectstore.StoreManager.getTxOJStore(StoreManager.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.txoj.recovery.TORecoveryModule.<init>(TORecoveryModule.java:73) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09-icedtea]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.newInstance0(Class.java:374) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_09-icedtea]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.common.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:194) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:444) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:861) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:113) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:460) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:130) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:110) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:113) [wildfly-transactions-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
--
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, 2 months
[JBoss JIRA] (JBTM-1871) Automatically add the "org.jboss.xts" dependency for XTS applications
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1871?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1871:
----------------------------------
Priority: Major (was: Minor)
> Automatically add the "org.jboss.xts" dependency for XTS applications
> ---------------------------------------------------------------------
>
> Key: JBTM-1871
> URL: https://issues.jboss.org/browse/JBTM-1871
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: TxBridge, TXFramework, XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M5
>
>
> At deployment time we should automatically add the org.jboss.xts dependency for applications that need it.
> We should be able to detect deployments that use XTS annotations (i.e those provided by the Compensations API) through Jandex. I'm not sure how we would detect those that don't use annotations; something to investigate.
--
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, 2 months
[JBoss JIRA] (JBTM-1871) Automatically add the "org.jboss.xts" dependency for XTS applications
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1871?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-1871:
---------------------------------------
I'll add the dependency if TXFramework annotations are present or webservices annotations are used together with transaction annotations.
> Automatically add the "org.jboss.xts" dependency for XTS applications
> ---------------------------------------------------------------------
>
> Key: JBTM-1871
> URL: https://issues.jboss.org/browse/JBTM-1871
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: TxBridge, TXFramework, XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.0.0.M5
>
>
> At deployment time we should automatically add the org.jboss.xts dependency for applications that need it.
> We should be able to detect deployments that use XTS annotations (i.e those provided by the Compensations API) through Jandex. I'm not sure how we would detect those that don't use annotations; something to investigate.
--
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, 2 months