June 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2372) Create integration test for JBTM-2356

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2372?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2372: ----------------------------------- Assignee: Amos Feng (was: Tom Jenkinson) > Create integration test for JBTM-2356 > ------------------------------------- > > Key: JBTM-2372 > URL: https://issues.jboss.org/browse/JBTM-2372 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.later > > > There was an integration test for it: https://github.com/jbosstm/narayana/commit/5b278de35b9095a27e27514cca4eea.... > However, it was failing on CI intermittently and had to be reverted. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2629. ------------------------------- Resolution: Out of Date This was done as part of the Spring Boot integration > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2627) Document JMS integration functionality

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2627?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2627: ----------------------------------- Assignee: (was: Tom Jenkinson) > Document JMS integration functionality > -------------------------------------- > > Key: JBTM-2627 > URL: https://issues.jboss.org/browse/JBTM-2627 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > > New JMS integration feature needs documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2806) Javadoc JMS module

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2806?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2806: ----------------------------------- Assignee: (was: Tom Jenkinson) > Javadoc JMS module > ------------------ > > Key: JBTM-2806 > URL: https://issues.jboss.org/browse/JBTM-2806 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1863) RESTAT Integration API does not allow participants to leave a transaction early

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1863?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-1863: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > RESTAT Integration API does not allow participants to leave a transaction early > ------------------------------------------------------------------------------- > > Key: JBTM-1863 > URL: https://issues.jboss.org/browse/JBTM-1863 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: REST > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 6.later > > > The restat integration API class org.jboss. narayana.rest.integration.api.ParticipantsManager interface does not allow participants to leave the transaction early (in the spec a participant can DELETE the participant-recovery URI to notify the coordinator that it is leaving the transaction early). > Question: The reportHeuristic method allows participants to leave the transaction after the termination protocol has started. To keep the interface simple would it be sensible to replace reportHeuristic with something that covered leaving a transaction at any time or would that be confusing normal operations with error conditions? If so then maybe just the converse of enlist? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2794) Javadoc compensations framework

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2794: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2733: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Adding section about inflow transactions and EIS interaction > ------------------------------------------------------------ > > Key: JBTM-2733 > URL: https://issues.jboss.org/browse/JBTM-2733 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. > This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2756) Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2756?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2756: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll > --------------------------------------------------------------------------------------- > > Key: JBTM-2756 > URL: https://issues.jboss.org/browse/JBTM-2756 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Static code analysis category: Nondeterministic locking behavior > _CID-17602_: Bad choice of lock object - Nondeterministic locking behavior > in class `ThreadAssociations` [1] at method `removeAll`. There is used synchronized block > where lock is acquired at `globalTxAssociations` and `txAssociations`. > The problem (one for txAssociations is described as) > lock_acquire: Acquiring lock `com.arjuna.ats.jts.extensions.`ThreadAssociations.txAssociations`. > lock_on_assigned_field: Locking on the object referenced by field `ThreadAssociations.txAssociations`. This lock acquisition may race with another thread assigning to this field. The contents of `ThreadAssociations.txAssociations` may change while a thread is inside the critical section, allowing two threads to enter the critical section simultaneously. > * Instead of using `ThreadAssociations.txAssociations` as a lock, create a final field of type Object which is only used as a lock. > assign_to_field: The expression `ThreadAssociations.txAssociations = null` assigns a new value to `ThreadAssociations.txAssociations`, a field whose contents are used as a lock. The locking behavior of this function may allow this assignment to occur multiple times. > Tom's reaction on this > {quote} > I think that the bug is that there is any synchronization at all on txAssociations because it looks to be indexed by Thread.currentThread(). > {quote} > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2757) ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2757?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2757: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2757 > URL: https://issues.jboss.org/browse/JBTM-2757 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > This issue came from Tom's investigation on JBTM-2756 (which came from static code analysis). > This issue points to the fact that for ThreadAssoction#add [1] tx is used as a getKey but then it overwrites the transactions associated with the thread. This seems to be a bug and need more investigation. > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2831: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/ma... > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues June 2017