[jboss-jira] [JBoss JIRA] (WFLY-6442) Inconsistent behavior of journal object store for heuristic state

[Tom Jenkinson (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson moved JBEAP-4001 to WFLY-6442:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-6442  (was: JBEAP-4001)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Transactions
                           (was: Transactions)
       Target Release:   (was: 7.0.0.GA)
    Affects Version/s:     (was: 7.0.0.ER7)
      Affects Testing:   (was: Regression)


> Inconsistent behavior of journal object store for heuristic state
> -----------------------------------------------------------------
>
>                 Key: WFLY-6442
>                 URL: https://issues.jboss.org/browse/WFLY-6442
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Ondřej Chaloupka
>            Assignee: Michael Musgrove
>            Priority: Blocker
>
> 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)