[jboss-jira] [JBoss JIRA] (WFLY-13516) Create integration test scenario for transaction recovery failure of ejb remoting JBEAP-19408

[Ondrej Chaloupka (Jira)]

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

Ondrej Chaloupka updated WFLY-13516:
------------------------------------
    Comment: was deleted

(was: The PR was closed as there is need first to have change of the Narayana filter priority to something else than the {USER} (https://github.com/jbosstm/narayana/blob/5.10.4.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeFilter.java#L50).
The issue is tracked at https://issues.redhat.com/browse/JBTM-3321.

There is needed the Narayana codebase to be changed and the component upgrade to be placed in.)


> Create integration test scenario for transaction recovery failure of ejb remoting JBEAP-19408
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-13516
>                 URL: https://issues.redhat.com/browse/WFLY-13516
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite, Transactions
>    Affects Versions: 20.0.0.Beta1
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>
> There was found a transaction recovery failure scenario which caused regression being filled as https://issues.redhat.com/browse/JBEAP-19408.
> The issue JBEAP-19408 causes that in case of WildFly communicating over EJB remoting to other WildFly and when there is a failure then there could be left prepared resources on the other WildFly which are never rolled-back.
> E.g. in case of database it means locked rows which could not be manipulated with until administrator comes and manually unlock them.
> The scenario which was this hit with and which should be simulated in the WildFly testsuite:
> * server A starts the transactions
> * transaction at server A enlists the an XAResource related to a future interation with server B (At server A, WFTC enlists an "ejb client resource" related to a future interaction with B)
> * server A makes the remote EJB call to server B where transaction is propagated
> * server A asks server B to prepare
> * server A creates a "ejb client resource" XAResourceRegistry file system record
> * server B prepares
> * server A crashes before it writes a transaction log
> * server A restarts  (transaction recovery cycle starts)
> * server A can see no record of the transactions in the object store
> * server A uses the standard orphan detection processing
> * server A calls XAResource.recover(TMSTARTRSCAN) on "ejb client resource". It returns prepared XAResources from server B as there is XAResourceRegistry file system record on server A (related to a future interation with server B)
> * server A calls XAResource.recover(TMENDRSCAN), the recovery cycle finishes
> * server A calls another round of recovery wwith XAResource.recover(TMSTARTRSCAN) and there is the XAResourceRegistry and orphan detection rolls-back the subtransaction resources on server B



--
This message was sent by Atlassian Jira
(v7.13.8#713008)