Abspaltung von #30047. Folge von #29767, siehe auch: #29108, #18518, #18690, #19415.

Kontext

Die Verwaltung der React-Benutzeroberfläche erfolgt über „admin/admin.view.xml“ von „tl-layout-view“ (Abschnitte „Zugriffskontrolle“, „Überwachung“, „System“; weitere Abschnitte stammen aus Overlays mit demselben Pfad, siehe den Entwicklerartikel „view-layer/overlays“). Die Verwaltung des Schedulers gab es bisher nur in der klassischen Benutzeroberfläche (admin/technical/scheduler/schedulerView.layout.xml).

Der Scheduler kannte zu viele Möglichkeiten, die Ausführung einer Aufgabe zu verhindern (#18518), die sich unterschiedlich verhielten:

• in der Aufgabenkonfigurationaktiviert (eine deaktivierte Aufgabe konnte dennoch manuell ausgeführt werden),
• Scheduler.enable() / disable() (lokal auf dem Clusterknoten, geht beim Neustart verloren),
• Sperrung durch den Administrator (blockTask() / unblockTask(), in der Datenbank gespeichert; eine gesperrte Aufgabe konnte nicht manuell ausgeführt werden),
• „blocked-by-default“ in der Aufgabenkonfiguration (Standardwert für die Sperrung),
• „blocking-allowed“ in der Aufgabenkonfiguration (ob der Administrator die Aufgabe überhaupt sperren darf).

Funktion

Ein Aktiv/Inaktiv-Schalter pro Aufgabe. Jede Aufgabe ist entweder aktiv (wird gemäß ihrer Zeitpläne eingeplant) oder inaktiv (wird niemals automatisch eingeplant). Der konfigurierte Wert für „aktiviert“ ist der Standardwert. Ein Administrator kann jede Aufgabe aktivieren oder deaktivieren; diese Auswahl wird in der Datenbank gespeichert, gilt für den gesamten Cluster und bleibt auch nach einem Neustart erhalten. Sie ist an den konfigurierten Wert gebunden, den sie überschreibt: Wenn eine Anwendungsaktualisierung den konfigurierten „enabled“-Wert der Aufgabe ändert, wird die gespeicherte Einstellung verworfen und der neue konfigurierte Wert gilt. „Auf konfigurierten Zustand zurücksetzen“ verwirft die gespeicherte Einstellung explizit. Das Aktivieren, Deaktivieren und Zurücksetzen wird in das Anwendungsprotokoll geschrieben.

„Jetzt ausführen“ startet sofort. „Jetzt ausführen“ startet jede Aufgabe, auch eine inaktive, sofort statt erst in der nächsten Abfrage-Runde des Schedulers (Standard: alle 10 Minuten). Das Ende eines Laufs (sein Ergebnis, die Freigabe seiner Cluster-Sperre) wird ebenfalls unmittelbar nach dem Lauf verarbeitet.

Scheduler-Ansicht im Abschnitt „System“ der React-Administration (Administration → System → Scheduler):

• eine Tabelle der Scheduler-Aufgaben (zusammengesetzte Aufgaben mit ihren Unteraufgaben) mit aktivem Status (konfiguriert oder von einem Administrator festgelegt), Zeitplan, letzter und nächstem Lauf, letztem Ergebnis, Ausführungsstatus und dem Clusterknoten, der die Sperre hält,
• Befehle, die jeweils nur dort angeboten werden, wo sie zutreffen: Jetzt ausführen, Stoppen (während der Ausführung, mit Bestätigung; die Stoppanforderung wird dem Benutzer zugeordnet), Aktivieren, Deaktivieren, Auf konfigurierten Zustand zurücksetzen, Cluster-Sperre freigeben, Aktualisieren und Konfiguration, wodurch die Konfiguration des Schedulers und seiner Aufgaben unter „System → Dienste“ geöffnet wird,
• eine Detailseite pro Aufgabe (Adresse …/scheduler/task/<Aufgabenname>) mit ihren Eigenschaften, ihrer Konfiguration einschließlich der Zeitpläne und dem Verlauf ihrer Ausführungen (Ergebnis, Start, Ende, Dauer, Clusterknoten, Meldung, Warnungen); ein Lauf öffnet ein Dialogfenster mit der vollständigen Meldung, den Warnungen, dem Stack-Trace einer Ausnahme (monospaced, Zeilen werden nicht umgebrochen, mit einer Schaltfläche zum Kopieren in die Zwischenablage) und der Protokolldatei des Laufs zum Herunterladen.

Das Freigeben einer Cluster-Sperre (beide Benutzeroberflächen) wird für eine knotenlokale oder nicht persistente Aufgabe, eine Aufgabe ohne Sperre sowie eine von diesem Clusterknoten gehaltene Sperre für einen hier noch laufenden Durchlauf verweigert (eine solche Sperre ist niemals veraltet). Die Bestätigungsmeldung weist auf das Risiko hin, die Aufgabe zweimal auszuführen; die Freigabe wird als Warnung zusammen mit der Aufgabe, dem Clusterknoten und dem ausführenden Benutzer protokolliert (#18690).

Die klassische Scheduler-Ansicht verwendet dieselbe Umschaltung: die Befehle „Aktivieren“, „Deaktivieren“ und „Auf konfigurierten Zustand zurücksetzen“ anstelle von „Sperren“/„Entsperren“ sowie eine Spalte „Aktiv“, die angibt, ob der Zustand konfiguriert oder von einem Administrator festgelegt wurde.

Vorformatierter mehrzeiliger Text. Die Annotation <multi-line> eines String-Attributs verfügt über die Option „vorformatiert“: Der Text wird in einer Schriftart mit fester Breite angezeigt, seine Zeilen werden nicht umgebrochen und lange Zeilen lassen sich horizontal scrollen – sowohl in der React- als auch in der klassischen Benutzeroberfläche, sowohl bearbeitbar als auch schreibgeschützt (z. B. für Stack-Traces, Protokollauszüge, JSON). In der React-Benutzeroberfläche bietet ein schreibgeschützter, vorformatierter Wert eine Schaltfläche zum Kopieren in die Zwischenablage (Teil „CopyButton“, durch eine kundeneigene Komponentenbibliothek ersetzbar).

Auf dem Weg zur Behebung

• Der Scheduler-Thread wartete auf einen „AtomicBoolean“-Monitor (#19415); er wartet nun auf eine Sperrbedingung, die auch das Aufwachen übernimmt.
• Aufgaben, die unter <on-startup/> geplant waren (z. B. „RefreshUsersTask“, die Benutzersynchronisation mit LDAP), wurden nicht direkt nach dem Anwendungsstart ausgeführt, sondern erst nach dem ersten Abfrageintervall des Schedulers (10 Minuten in der Engine-Konfiguration): Jede Runde des Dispatch-Threads, auch die erste, wartete das Abfrageintervall ab, bevor die fälligen Aufgaben gestartet wurden. Die erste Runde startet die fälligen Aufgaben nun direkt, sobald der Scheduler mit der Verteilung beginnt, d. h. sobald die Anwendung gestartet ist.
• React-UI: Ein Befehl wurde bei der Sitzungsrevision der vorherigen Anfrage des Fensters ausgeführt, sodass er die Commits anderer Threads nicht erkannte (z. B. zeigte „Refresh“ eine Aufgabe nach Beendigung ihrer Ausführung weiterhin als „wird abgebrochen“ an). Das Fenster wird nun auf den letzten festgeschriebenen Zustand gebracht, bevor ein Befehl (sowie ein Upload und eine Navigation per URL) ausgeführt wird.
• Die Testaufgabe „InstructableTestTask“ reagiert auf eine Stoppanforderung und kann eine Protokolldatei für ihre Durchläufe erstellen („write-log-file“).

Demo

tl-demo-react enthält Demo-Aufgaben, die jede Situation veranschaulichen: eine lang laufende Aufgabe (zum Stoppen), eine fehlgeschlagene Aufgabe (Stack-Trace), eine Aufgabe mit Warnungen und einer Protokolldatei, eine durch Konfiguration inaktive Aufgabe sowie eine clusterweite Aufgabe mit Cluster-Sperre.

Überprüfung

tl-demo-react (/view/, root / root1234), Administration → System → Scheduler; klassische Benutzeroberfläche tl-demo, Administration → Technische Administration → Steuerprogramm. Tests: TestScheduler (Umschaltung, gespeicherte Auswahl, Übernahme gespeicherter Blöcke, sofortiger Start, Freigabe der Cluster-Sperre und deren Verweigerung, Protokolldatei), TestSchedulerOnStartup (eine <on-startup/> -Aufgabe läuft unmittelbar nach dem Start des Schedulers mit einem Abfrageintervall von einer Stunde, eine noch nicht fällige Aufgabe hingegen nicht), TestCommandSeesForeignCommit (React-Befehl erkennt einen Commit eines anderen Threads), Testfälle für die Komponenten „FieldValue“, „TextInput“ und „CopyButton“ (TopLogic und MUI-Zeichnung).

Migration

• Die Aufgabenkonfigurationseigenschaft „blocked-by-default“ wurde entfernt. Ersetzen Sie „blocked-by-default="true"“ durch „enabled="false"“.
• Die Task-Konfigurationseigenschaft „blocking-allowed“ wurde ohne Ersatz entfernt; jeder Task kann von einem Administrator aktiviert und deaktiviert werden.
• Scheduler.enable(Task) / disable(Task) / isTaskEnabled(Task) / isEnabled(Task) sowie blockTask(Task) / unblockTask(Task) / isTaskBlocked(Task) werden durch activate(Task) / deactivate(Task) / isActive(Task) / resetActive(Task) ersetzt. Scheduler.isBlockingAllowed(Task) und Task.isBlockingAllowed() wurden entfernt.
• Klassische Scheduler-Ansicht: Die Befehlshandler `blockTask ` / `unblockTask` werden durch `deactivateTask ` / `activateTask ` (sowie `resetTaskActive`) ersetzt; die Klassen wurden von `com.top_logic.util.sched.layout.block ` nach `com.top_logic.util.sched.layout.active` verschoben. Die Tabellenspalten „isBlocked“, „isEnabled“ und „isBlockingAllowed“ werden durch „active“ ersetzt. Anwendungslayouts, die darauf verweisen, müssen angepasst werden.
• In der Datenbank gespeicherte Sperrzustände werden automatisch als Einstellung des Administrators übernommen (blocked = inaktiv, unblocked = aktiv).
• Eine Kundenkomponentenbibliothek, die das React-Teil „FieldValue“ ersetzt, erhält die optionalen Props „preformatted “ und „action“; die Teilliste enthält das Teil „CopyButton“.
• Weitere entfallene API-Elemente: die Filter „com.top_logic.util.sched.entry.filter.EnabledSchedulerEntryFilter“ und „ManuallyStartedSchedulerEntryFilter“, die Klassen „BlockState“ und „BlockStateRenderer“ (com.top_logic.util.sched.layout.block), TaskImpl.isBlockedByDefault() sowie bei SchedulerEntry der Konstruktor SchedulerEntry(Task, boolean) und die Methoden setEnabled / isEnabled / setAttached / isAttached / createThread. Eigene Layouts und eigener Code, der diese verwendet, fragen stattdessen Scheduler.isActive(Task) ab bzw. entfernen die Verwendung.