Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-8616

Distributed workmanager does not execute work on other nodes than where the work was scheduled

XMLWordPrintable

    • Hide

      I'll attach a quick and dirty reproducer script. It downloads a fork of WFLY that contains a WIP DwmTest and runs it. If the test passes, go into testsuite/integration/basic/target/surefire-reports and have a look at the test logs. The statistics of where the work was scheduled and executed are logged there. If the test fails, rerun it - there are some Infinispan exceptions that I need to investigate.

      I'll also attach an ear containing the resource adapter that makes use of the dwm (the ear has been exported from DwmTest). To set up EAP properly for use with the dwmtest.ear, use:

      batch
/subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm)
/subsystem=jca/distributed-workmanager=newdwm/short-running-threads=newdwm:add(queue-length=10,max-threads=10)
/subsystem=jca/bootstrap-context=customContext1:add(name=customContext1,workmanager=newdwm)
run-batch
reload
      Show
      I'll attach a quick and dirty reproducer script. It downloads a fork of WFLY that contains a WIP DwmTest and runs it. If the test passes, go into testsuite/integration/basic/target/surefire-reports and have a look at the test logs. The statistics of where the work was scheduled and executed are logged there. If the test fails, rerun it - there are some Infinispan exceptions that I need to investigate. I'll also attach an ear containing the resource adapter that makes use of the dwm (the ear has been exported from DwmTest). To set up EAP properly for use with the dwmtest.ear , use: batch /subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm) /subsystem=jca/distributed-workmanager=newdwm/ short -running-threads=newdwm:add(queue-length=10,max-threads=10) /subsystem=jca/bootstrap-context=customContext1:add(name=customContext1,workmanager=newdwm) run-batch reload

      Scenario: we have two EAP servers, both of them have a distributed workmanager set up. We try to schedule some work on one of the servers (via scheduleWork() and since we have a policy of ALWAYS, the work should be executed on a node different from the one where it was scheduled. However, it is always executed on the same node.

      This might be related to or even caused by JBEAP-9418.

      I think this is severe enough to warrant a beta blocker label - the DWM can be configured and you can pass work instances to it, but they will never be executed on remote nodes. In effect, policy options other than NEVER do not work. I'm raising the priority to blocker accordingly.

      This also blocks EAP7-495.

              smaestri@redhat.com Stefano Maestri
              smaestri@redhat.com Stefano Maestri
              Richard Janik Richard Janik
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: