Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-5732

No error message on concurrent processing of the same inflow transaction

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.1.0.DR9
    • 7.1.0.DR3
    • JCA
    • None
    • Hide

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

      git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
export JBOSS_HOME=...
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, Narayana 5.3.3.Final) git clone http: //git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... 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 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.

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

      Attachments

        Issue Links

          is cloned by

          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

          Bug - A problem that impairs or prevents the functions of the product. JBJCA-1329 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.
          • Resolved
          is related to

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. JBEAP-6133 (7.1.0) Upgrade to IronJacamar 1.4.0 when released

          • 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)
              Ondrej Chaloupka Ondrej Chaloupka (Inactive)
              Ondrej Chaloupka Ondrej Chaloupka (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: