April 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2650) Remove typo from BAControler interface and its implementations

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2650?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Gytis Trikleris created pull request #999 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Remove typo from BAControler interface and its implementations > -------------------------------------------------------------- > > Key: JBTM-2650 > URL: https://issues.jboss.org/browse/JBTM-2650 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Fix typos in BAControler, LocalBAControler, and RemoteBAControler names. Also variables when those classes are used also have typos. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2649. ------------------------------- > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.16.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2649. --------------------------------- Resolution: Done > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.2.Final, 5.2.16.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2649: -------------------------------- Fix Version/s: 5.2.16.Final (was: 5.2.15.Final) > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.16.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2649: -------------------------------- Affects Version/s: 5.2.15.Final > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.16.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2649: --------------------------------- Not in 5.2.15.Final! > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.15.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > * enlist activemq JMS resource > * enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}} > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2641) Add localisation to JMS module warnings

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2641?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Gytis Trikleris created pull request #998 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add localisation to JMS module warnings > --------------------------------------- > > Key: JBTM-2641 > URL: https://issues.jboss.org/browse/JBTM-2641 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Warning messages in JMS modules should be localised same as other modules in ArjunaJTA. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.... ] Tomas Hofman updated JBTM-2643: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.3.2.Final (was: 5.next) Resolution: Done > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 5.3.2.Final > > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2579) Throw XAException in XATerminator::commit if a wrapped resource fails transiently

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2579: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1325726|https://bugzilla.redhat.com/show_bug.cgi?id=1325726] from NEW to MODIFIED > Throw XAException in XATerminator::commit if a wrapped resource fails transiently > --------------------------------------------------------------------------------- > > Key: JBTM-2579 > URL: https://issues.jboss.org/browse/JBTM-2579 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.31, 5.2.9.Final > > > It is possible for a resource that we are wrapping to return say XA_RETRY or XA_RMFAIL and therefore end up in the BasicAction failed list. However there is no error returned from commit in this circumstance as the recovery manager should ensure a consistent outcome. > The reason this becomes a problem for JTA and XATerminator in particular is that as no error is returned a parent coordinator will assume the branch completed successfully. In the future when it calls XATerminator::recover though this branch will be returned and detected as an orphan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (JBTM-2652) Include STM javadocs on narayana.io

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2652: ----------------------------------- Summary: Include STM javadocs on narayana.io Key: JBTM-2652 URL: https://issues.jboss.org/browse/JBTM-2652 Project: JBoss Transaction Manager Issue Type: Task Components: Documentation, STM Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Should be part of http://narayana.io/docs/api/index.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2016