Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-2819

Recover operation does not work for participant of JCA type transactions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Rejected
    • Affects Version/s: 5.4.0.Final
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Steps to Reproduce:
      Hide
      • download DR9 at http://download-ipv4.eng.brq.redhat.com/devel/candidates/JBEAP/JBEAP-7.1.0.DR9/jboss-eap-7.1.0.DR9.zip
      • unzip jboss-eap-7.1.0.DR9.zip && cd jboss-eap-7.1
      • unzip heuristic-rollback-objectstore.zip
      • change standalone-full.xml to run with jts
      • /bin/standalone.sh -c standalone-full.xml
      • ./bin/jboss-cli.sh -c
        • /subsystem=transactions/log-store=log-store:probe
        • /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover
        • /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource

      or crashrec testsuite shows this when run

      mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTA -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery
      
      Show
      download DR9 at http://download-ipv4.eng.brq.redhat.com/devel/candidates/JBEAP/JBEAP-7.1.0.DR9/jboss-eap-7.1.0.DR9.zip unzip jboss-eap-7.1.0.DR9.zip && cd jboss-eap-7.1 unzip heuristic-rollback-objectstore.zip change standalone-full.xml to run with jts /bin/standalone.sh -c standalone-full.xml ./bin/jboss-cli.sh -c /subsystem=transactions/log-store=log-store:probe /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource or crashrec testsuite shows this when run mvn clean verify -am -pl jbossts -DfailIfNoTests= false -fn -Djbossts.noJTA -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery

      Description

      Jboss cli :recover operation does not work when having JCA type transaction. My test shows following

      [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:probe
      {"outcome" => "success"}
      [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true)
      {
          "outcome" => "success",
          "result" => {
              "expose-all-logs" => false,
              "type" => "default",
              "transactions" => {
                  "0:ffff7f000001:-4cecb39b:585109e2:31" => {
                      "age-in-seconds" => undefined,
                      "id" => "0:ffff7f000001:-4cecb39b:585109e2:31",
                      "jmx-name" => undefined,
                      "type" => "CosTransactions/XAResourceRecord",
                      "participants" => undefined
                  },
                  "0:ffff7f000001:-4cecb39b:585109e2:28" => {
                      "age-in-seconds" => "1481798762",
                      "id" => "0:ffff7f000001:-4cecb39b:585109e2:28",
                      "jmx-name" => undefined,
                      "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA",
                      "participants" => {"0:ffff7f000001:-4cecb39b:585109e2:31" => {
                          "eis-product-name" => "unavailable",
                          "eis-product-version" => "unavailable",
                          "jmx-name" => undefined,
                          "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31",
                          "status" => "HEURISTIC_ROLLBACK",
                          "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord"
                      }}
                  }
              }
          }
      }
      
      [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:recover
      {"outcome" => "success"}
      [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store/transactions=0\:ffff7f000001\:-4cecb39b\:585109e2\:28/participants=0\:ffff7f000001\:-4cecb39b\:585109e2\:31:read-resource
      {
          "outcome" => "success",
          "result" => {
              "eis-product-name" => "unavailable",
              "eis-product-version" => "unavailable",
              "jmx-name" => undefined,
              "jndi-name" => "0:ffff7f000001:-4cecb39b:585109e2:31",
              "status" => "HEURISTIC_ROLLBACK",
              "type" => "/StateManager/AbstractRecord/ExtendedResourceRecord"
          }
      }
      

      I expect that :recover put the participant to PREPARED state and at that point RAR XATerminator.commit could commit such participant.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  mmusgrov Michael Musgrove
                  Reporter:
                  ochaloup Ondrej Chaloupka
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: