Improve External task Fetch and Lock Hit Rate

XMLWordPrintable

    • Type: Feature Request
    • Resolution: Fixed
    • Priority: L3 - Default
    • 7.14.0, 7.14.0-alpha3
    • Affects Version/s: 7.11.2
    • Component/s: engine
    • None

      When there are multiple workers querying the same topics, they may select the same task for acquisition. For each task, the corresponding execution is selected in order to collect its variables. In concurrency situations, the execution may not exist anymore, which lets the fetch and lock command fail with a NullValueException. As the absence of the execution indicates a concurrent modification, this scenario should be treated like OptimisticLockingException when locking the task, i.e. the task should be removed from the result set and the command should not fail.

      Example:

      Let's assume there are 5 tasks (tasks 1-5) in the database and there are two workers (worker 1 and worker 2).

      Let's also assume both workers send a fetch and lock request concurrently and

      • worker 1 attempts to lock Tasks 1-4
      • worker 2 attempts to lock Tasks 4-5

      Current behavior

      Assuming that worker 1 commits first and immediately completes task 4 (while worker 2 is still in the fetch and lock command), worker 2 may fail when selecting task 4's execution, which lets the fetch and lock command fail.

      Proposed behavior

      Worker 2 should ignore the conflict on the execution and come back with task 5.

      Context

      This is already the implemented behavior in case of concurrent modifications on the task itself.

        This is the controller panel for Smart Panels app

              Assignee:
              Thorben Lindhauer
              Reporter:
              Ilias
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: