Details

    • Target Release:
    • Steps to Reproduce:
      Hide

      Could be reproduce with transaction crash recovery testsuite with test

      mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=TxPropagationJMSCrashRecoveryTestCase#commitHaltServer
      

      where the "workaround" needs to be removed from the test code at jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/txpropagation/test/delegate/TxPropagationTests.java in method commitHaltServer. It's needed to comment line delegatedTest.callDoNothing();. Then test starts to fail.

      Show
      Could be reproduce with transaction crash recovery testsuite with test mvn clean verify -am -pl jbossts -DfailIfNoTests= false -fn -Djbossts.noJTS -Dtest=TxPropagationJMSCrashRecoveryTestCase#commitHaltServer where the "workaround" needs to be removed from the test code at jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/txpropagation/test/delegate/TxPropagationTests.java in method commitHaltServer . It's needed to comment line delegatedTest.callDoNothing(); . Then test starts to fail.
    • Affects:
      Release Notes
    • Release Notes Docs Status:
      Documented as Known Issue
    • Release Notes Text:
      Hide
      Transaction recovery operations can fail if they involve remote EJB resources that may have crashed. The issue presents because when a connection breaks down between the server and the client (specifically when the client crashes and is restarted); the server and the client will not automatically communicate with each other. In these scenarios, the server will have no knowledge that the client has started again, effectively meaning that the EJB tx recovery process will not know which EJB nodes to communicate with.
      Show
      Transaction recovery operations can fail if they involve remote EJB resources that may have crashed. The issue presents because when a connection breaks down between the server and the client (specifically when the client crashes and is restarted); the server and the client will not automatically communicate with each other. In these scenarios, the server will have no knowledge that the client has started again, effectively meaning that the EJB tx recovery process will not know which EJB nodes to communicate with.

      Description

      This issue is port of bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=952746 from EAP 6.4.x.

      There is problem for EJB remote calls which propagate transaction when remote outbound connection is used for doing such remote call that in case that recovery is needed then ejb client does not automatically resurrect connection when the callee crashed during 2PC.

      The scenario is like:
      1. enlist and use 2 XA resources on server 1
      2. call an ejb on server 2
      3. enlist and use 2 XA resources on server 2
      4. prepare phase - preparing all 4 resources on both servers
      5. commit phase starts
      6. crash JVM of server 2
      7. start server 2 once again
      8. run recovery

      As the connection is not automatically up when server 2 is started then recovery process can't finish the in-doubt transaction. There is "a workaround" to call an ejb from server 1 to server 2 at time when server 2 is up again. When this happens the connection is established and recovery can proceed.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  dmlloyd David Lloyd
                  Reporter:
                  ochaloup Ondrej Chaloupka
                  Tester:
                  Daniel Simko
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  11 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: