[JBoss JIRA] (JBTM-2970) Investigate on transaction SPI usage and if necessary for WFLY integration
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2970:
-------------------------------------
Summary: Investigate on transaction SPI usage and if necessary for WFLY integration
Key: JBTM-2970
URL: https://issues.jboss.org/browse/JBTM-2970
Project: JBoss Transaction Manager
Issue Type: Task
Components: Application Server Integration, SPI
Affects Versions: 5.7.1.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
Attachments: eap6-txn-dependencies.jpg, eap71-txn-dependencies.jpg
The transaction integration code in WFLY is pretty complicated. With the introduction of WildFly transaction client come one more layer of abstraction and especially it should be rethought what is the reason for using SPI there.
More than half a classes in SPI are deprecated. It would be good to understand if they are necessary or if some refactoring would be beneficial.
As an ilustration attaching a graphic of transaction dependencies in WildFly 11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (JBTM-2969) Make the CDI checker a standalone tool or/and mvn plugin
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2969:
-------------------------------------
Summary: Make the CDI checker a standalone tool or/and mvn plugin
Key: JBTM-2969
URL: https://issues.jboss.org/browse/JBTM-2969
Project: JBoss Transaction Manager
Issue Type: Bug
Components: LRA
Affects Versions: 5.7.1.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
The way how the checker works now (as CDI extension, needed to be packed inside of the app) is not a good approach and it should work as a standalone tool or better as a maven plugin to verify the annotation in a defined phase.
The current approach needs to be reworked.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2961?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka closed JBTM-2961.
---------------------------------
Resolution: Done
After talk with Mike I need to use another approach with the checker. Closing this one, currently leaving the cdi checker ignored from the lra build.
> CDI checker has to start test swarm containers as process
> ---------------------------------------------------------
>
> Key: JBTM-2961
> URL: https://issues.jboss.org/browse/JBTM-2961
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: REST
> Affects Versions: 5.7.1.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Attachments: console,.txt
>
>
> This is a follow-up to JBTM-2932.
> The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment.
> But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (JBTM-2889) Include a vertx with STM quickstart
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2889?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #216 in GitHub
----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Reopened)
> Include a vertx with STM quickstart
> -----------------------------------
>
> Key: JBTM-2889
> URL: https://issues.jboss.org/browse/JBTM-2889
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: Demonstrator, STM
> Affects Versions: 4.2
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Optional
> Fix For: 5.6.0.Final
>
>
> It would be useful to include a quickstart that shows how to use STM with vertx
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2948:
--------------------------------
Fix Version/s: 5.next
(was: 5.7.2.Final)
> NullPointer exception when beforeCompletion callback fails to prepare
> ---------------------------------------------------------------------
>
> Key: JBTM-2948
> URL: https://issues.jboss.org/browse/JBTM-2948
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core, XTS
> Affects Versions: 5.7.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Fix For: 5.next
>
>
> In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed.
> This situation could happen in case of trouble of WS-AT XTS of volatile participant.
> Let's look at the stack trace talk.
> First this is a failure of the beforeCompletion
> {code}
> TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
> WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException
> at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98)
> at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147)
> at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200)
> at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193)
> TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING)
> WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization@5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false
> {code}
> as that failure happens we can see the later {{NullPointer}}
> {code}
> WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD
> WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource@3d67708e) failed with exception code -: java.lang.NullPointerException
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961)
> at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240)
> at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246)
> at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2961?page=com.atlassian.jira.plugin.... ]
Michael Musgrove edited comment on JBTM-2961 at 11/22/17 11:58 AM:
-------------------------------------------------------------------
I pushed a commit that temporarily disables the lra cdi checker whilst we investigate why it is failing on mac builds.
was (Author: mmusgrov):
I pushed a commit tha temporarily disabling the lra cdi checker whilst we investigate why it fails on mac builds.
> CDI checker has to start test swarm containers as process
> ---------------------------------------------------------
>
> Key: JBTM-2961
> URL: https://issues.jboss.org/browse/JBTM-2961
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: REST
> Affects Versions: 5.7.1.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Attachments: console,.txt
>
>
> This is a follow-up to JBTM-2932.
> The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment.
> But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years