Uploaded image for project: 'IronJacamar'
  1. IronJacamar
  2. JBJCA-1329

No error message on concurrent processing of the same inflow transaction

    XMLWordPrintable

Details

    • Hide

      Crashrecovery testsuite could be used for reproducing the issue.
      Tested with JBoss EAP 7.1.0.DR3 (IronJacamar 1.3.4.Final)

      git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
export JBOSS_HOME=...
unignore test {{multipleWorkSharedXidInBunch}}
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Dtest=JcaInflowTransactionTestCase#multipleWorkSharedXidInBunch
      Show
      Crashrecovery testsuite could be used for reproducing the issue. Tested with JBoss EAP 7.1.0.DR3 (IronJacamar 1.3.4.Final) git clone http: //git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... unignore test {{multipleWorkSharedXidInBunch}} mvn clean verify -am -pl jbossts -DfailIfNoTests= false -fn -Dtest=JcaInflowTransactionTestCase#multipleWorkSharedXidInBunch

    Description

      I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed.

      This is the scenario which behaves wrong by my view

      • EIS passes a message with xid1 to RAR to be processed
      • first message is passed as work to be process (stays in progress)
      • EIS passes a second message with xid1 to RAR to be processed
      • the second message is forgotten. It will never reach a MessageListner
        • no error is returned or shown in log

      Compared following scenario passes without a problem.

      • EIS passes a message with xid1 to RAR to be processed
      • first message is fully processed with MessageListner (it reaches the end of the onMessage method)
      • EIS passes a second message with xid1 to RAR to be processed
      • second message is processed by MessageListener

      From logging I can see that work was cancelled [2] by call of WorkWrapper [1]. But any information is forgotten. There is no error message in the log and there is wrong type and listnener methods called (javax.resource.spi.work.WorkListener by workCompleted with work type defined with status 4) for such messages.
      If I do understand right the jca specification says that WorkCompletedException needs to be shown[3].

      [1] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/org/jboss/jca/core/workmanager/WorkWrapper.java#L459
      [2]

      2016-08-25 09:28:32,688 TRACE [org.jboss.jca.core.workmanager.WorkWrapper] (default-threads - 4) Cancel work: WorkWrapper@1755d562[workManger=org.jboss.as.connector.services.workmanager.NamedWorkManager@dcb0b17[id=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter-default name=default specCompliant=true shortRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@5c446e25 longRunningExecutor=org.jboss.jca.core.workmanager.StatisticsExecutorImpl@170ccc4f xaTerminator=org.jboss.jca.core.tx.jbossts.XATerminatorImpl@57da418e validatedWork=[org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork, org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] callbackSecurity=null securityIntegration=org.jboss.jca.core.security.picketbox.PicketBoxSecurityIntegration@78ad9dc3 resourceAdapter=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceAdapter@fc1a5071 shutdown=false activeWorkWrappers=[WorkWrapper@5715513d] statistics=WorkManagerStatistics@71bdb84[active=1 successful=6 failed=0 doWorkAccepted=0 doWorkRejected=0 scheduleWorkAccepted=6 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.jboss.as.test.jbossts.crashrec.jca.rar.TxnWork@241d1e13 xid=formatId=4660 gtrid(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} bqual(64)={0x7f00000100000000010000002a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000} txTimeout=-1 workListener=org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceWorkListner@40b572b1 workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA016068: Work already active!, error code: 2]

      [3]

      The application server must reject Work submissions for a transaction whosecompletion is in-progress, with a WorkCompletedException set to the errorcode WorkException.TX_CONCURRENT_WORK_DISALLOWED.

      Attachments

        Issue Links

          causes

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-7035 [QE](7.0.z) No error message on concurrent processing of the same inflow transaction

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-5732 No error message on concurrent processing of the same inflow transaction

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Activity

            People

              smaestri@redhat.com Stefano Maestri
              ochaloup@redhat.com Ondrej Chaloupka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: