November 2017 - jbossts-issues - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (JBTM-2221) Remove old TXFramework API

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-2221: --------------------------------------- We've mentioned this at the meeting and this should be considered for version 6.0.0 when it comes. > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 6.later > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2221) Remove old TXFramework API

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka reassigned JBTM-2221: ------------------------------------- Assignee: Ondra Chaloupka (was: Paul Robinson) > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 6.later > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2942) LRA tests failed when building with the JDK9

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2942?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-2942: --------------------------------------- The Swarm issue on supporting JDK9 is here: https://issues.jboss.org/browse/SWARM-1594 > LRA tests failed when building with the JDK9 > -------------------------------------------- > > Key: JBTM-2942 > URL: https://issues.jboss.org/browse/JBTM-2942 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Amos Feng > Assignee: Amos Feng > Labels: jdk9 > > The lra-test still failed with java.lang.IllegalArgumentException when deploying the war. It looks like the wildfly-swarm does support the JDK9 currently. Also I find 1 and 2 with the same issues. > 1. https://stackoverflow.com/questions/46449735/wildfly-swarm-deployment-cra... > 2. https://stackoverflow.com/questions/42990017/illegalargumentexception-whi... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

[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.... ] Michael Musgrove reopened JBTM-2889: ------------------------------------ I am reopening since I want to replace the quickstart with a link to a [better one|https://github.com/jbosstm/conferences/tree/master/mucon2017] in our conferences repositiory: > 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, 1 month

1
0
0 / 0

[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, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2017