JS - JobScheduler
  1. JS - JobScheduler
  2. JS-1834

Orders waiting in a stopped node or suspended orders are not reset to initial state after a JobScheduler restart.

    Details

      Description

      Current Situation

      When an order is suspended in a job chain or is waiting at a stopped node and during the run of the order new parameters have been added to the order or parameters have been changed and the JobScheduler will be restarted, the order will not be resetted to initial state when the order has finished the job chain e.g. after unstopping all nodes.

      Desired Behavior

      Orders should be resetted to initial state even when proceeding run after a JobScheduler restart.

      How to reproduce

      • Create a job chain
      • add a persistent order
      • stop one node
      • start the order with JOC
      • add a parameter with one job in the chain
        • spooler_task.order.params.set_var("newparam","value");
      • when order has reached the stopped node, restart JobScheduler
      • unstop the order

      The order will now continue running in the job chain. When finished and have been set to first node, the order has all parameters that have been added during execution e.g. 'SCHEDULER_JOC_USER_ACCOUNT'

      This can also be verified in the table SCHEDULER_ORDERS where the field payload contains all parameters that have been set during the last execution

        Issue Links

          Activity

          Hide
          Andreas Püschel added a comment -

          Sorry, vielleicht falle ich hier in der Diskussion zurück, aber ggf. könnt ihr helfen:

          • Uwe Risse, wie ist dein Kommentar gemeint? Hat der von dir in der Description geschilderte Fall die Default Einstellung <param name="scheduler.order.keep_order_content_on_reschedule" value="false"/> verwendet? Dies scheint eine relevane Information zu sein.
          • Joacim Zschimmer, ja, ist klar. Die ursprünglichen Auftragsvariablen stehen ebenfalls in *.order.xml, da der Fall von einem permanenten Order ausgeht. Meine Erwartung wäre, dass nach Neustart und Abschluss des Auftragslaufs die Auftragsvariablen aus *.order.xml verwendet werden. Oder ist das Verhalten derzeit anders, dass aus *.order.xml nur beim Neustart und anlässlich des Einlesens der Konfiguration gelesen wird, nicht aber wenn beim Neustart (ggf. geänderte) Auftragsvariablen bereits in der Datenbank vorhanden sind und deshalb nach Abschluss des Auftragslauf nicht die ursprünglichen Auftragsvariablen restauriert werden?
          Show
          Andreas Püschel added a comment - Sorry, vielleicht falle ich hier in der Diskussion zurück, aber ggf. könnt ihr helfen: Uwe Risse , wie ist dein Kommentar gemeint? Hat der von dir in der Description geschilderte Fall die Default Einstellung <param name="scheduler.order.keep_order_content_on_reschedule" value="false"/> verwendet? Dies scheint eine relevane Information zu sein. Joacim Zschimmer , ja, ist klar. Die ursprünglichen Auftragsvariablen stehen ebenfalls in *.order.xml, da der Fall von einem permanenten Order ausgeht. Meine Erwartung wäre, dass nach Neustart und Abschluss des Auftragslaufs die Auftragsvariablen aus *.order.xml verwendet werden. Oder ist das Verhalten derzeit anders, dass aus *.order.xml nur beim Neustart und anlässlich des Einlesens der Konfiguration gelesen wird, nicht aber wenn beim Neustart (ggf. geänderte) Auftragsvariablen bereits in der Datenbank vorhanden sind und deshalb nach Abschluss des Auftragslauf nicht die ursprünglichen Auftragsvariablen restauriert werden?
          Hide
          Andreas Püschel added a comment -

          Hallo @ur,

          zu deinem Kommentar von 11:02

          • mir ist wichtig, dass alle Beteiligten incl. Reporter und Approver, nachvollziehen können, was geändert wird und weshalb.
          • das Verhalten ist derzeit nach einem Neustart anders, da der (unterbrochene) Auftrag in der Datenbank seine ggf. geänderten Auftragsvariablen hält und verwendet (das soll auch so sein) und nach Neustart und Abschluss des Auftragslaufs die ursprünglichen Auftragsvariablen nicht in der Datenbank verfügbar sind. Die Auftragsvariablen sind in der Konfiguration verfügbar, diese wird aber derzeit nicht erneut eingelesen, da der Startzeitpunkt des Master bereits zurückliegt. Die Lösung hat zum Gegenstand die ursprünglichen Aufragsvariablen im beschriebenen Fall wiederherzustellen.
          • JS-856 beschreibt, was Stefan damals geändert haben wollte und weshalb, daher ist der Hinweis auf dieses Issue hilfreich.
          Show
          Andreas Püschel added a comment - Hallo @ur, zu deinem Kommentar von 11:02 mir ist wichtig, dass alle Beteiligten incl. Reporter und Approver, nachvollziehen können, was geändert wird und weshalb. das Verhalten ist derzeit nach einem Neustart anders, da der (unterbrochene) Auftrag in der Datenbank seine ggf. geänderten Auftragsvariablen hält und verwendet (das soll auch so sein) und nach Neustart und Abschluss des Auftragslaufs die ursprünglichen Auftragsvariablen nicht in der Datenbank verfügbar sind. Die Auftragsvariablen sind in der Konfiguration verfügbar, diese wird aber derzeit nicht erneut eingelesen, da der Startzeitpunkt des Master bereits zurückliegt. Die Lösung hat zum Gegenstand die ursprünglichen Aufragsvariablen im beschriebenen Fall wiederherzustellen. JS-856 beschreibt, was Stefan damals geändert haben wollte und weshalb, daher ist der Hinweis auf dieses Issue hilfreich.

            People

            • Assignee:
              Joacim Zschimmer
              Reporter:
              Uwe Risse
              Approver:
              Mahendra Patidar
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: