Anwendungsvorgänge in der Warteschlange

CICD-APIs, die die instanzweite Sperre/den Mutex erhalten müssen, um die angeforderten Vorgänge auszuführen, werden in die Warteschlange gestellt und nicht abgelehnt, wenn die instanzweite Sperre/der Mutex durch die anderen Vorgänge belegt ist.

Ab Tokyo werden die CICD-APIs, die die Aktualisierungsinstanz -weite Sperre/Mutex benötigen, um die angeforderten Vorgänge auszuführen, in die Warteschlange gestellt, anstatt abgelehnt zu werden, wenn die Aktualisierungsinstanz -weite Sperre/Mutex von den anderen Vorgängen belegt ist. Wenn eine CICD-Anforderung empfangen wird, erstellt der entsprechende CICD-Service eine Anwendungsvorgangs-NowMQ-Nachricht (Now Message Queue) und fügt die Nachricht mithilfe von NowMQ-APIs in die Warteschlange ein. Die Nachrichten in der Warteschlange werden dann von der geplanten Aufgabe abgefragt und einzeln oder parallel verarbeitet, wenn die parallele Verarbeitung aktiviert ist und der Vorgang die erforderlichen Kriterien erfüllt.

Anwendungsvorgang NowMQ-Nachricht

Die NowMQ-Nachrichten des Anwendungsvorgangs haben den gemeinsamen Betreff „sys.applifecycle.operation“. Der Nachrichtentext der NowMQ-Nachricht des Anwendungsvorgangs enthält ein JSON-Objekt, das die sys_id der Ausführungsnachverfolgung (auch als Fortschritts-ID bezeichnet, die in der CICD-API-Antwort zurückgegeben wird) enthält. Der Vorgangstyp kann einer der folgenden sein: app_install, „plugin_activation“, „batch_install“, „rollback“, „import_app“ und „apply_changes“. Sie enthält auch Informationen wie Plugin-ID für die Plugin-Aktivierung, App-ID oder Umfang für die Anwendungsinstallation.

Ausführungsnachverfolgung für Anwendungsvorgang

Wenn die NowMQ-Nachricht des Anwendungsvorgangs erstellt und eingefügt wird, wird der Execution Tracker-Datensatz für die entsprechende CICD-Anforderung erstellt und seine sys_id wird dem Text der NowMQ-Nachricht hinzugefügt. Die Ausführungsnachverfolgung befindet sich anfänglich im Status „Ausstehend“. Die Spalte „Details“ der Ausführungsnachverfolgung enthält die Informationen zur Art des Vorgangs und die wichtigen Eingabeparameter für die CICD-Anforderung. Die Spalte „Nachricht“ enthält die Informationen zur Warteschlangenposition. Wenn die Warteschlange angehalten ist, wird der Nachricht das Präfix „[Warteschlange für App-Vorgänge ist angehalten]“ vorangestellt.

Beispiel für Ausführungstracker für Anwendungsvorgänge, wenn die Warteschlange ausgeführt wird.

Beispiel für Nachverfolgungen von Anwendungsvorgängen, wenn die Warteschlange angehalten ist.

Hinweis:

Vorgänge, die sich im Status „Ausstehend“ befinden, werden im aktuellen Verlauf nicht angezeigt.

Beispielanwendungsvorgänge – Ausführungstracker – aktueller Verlauf. Aktueller Verlauf zeigt Vorgänge im Verlauf an, die in den letzten 24 Stunden in die Warteschlange gestellt und verarbeitet wurden.

Verwalten der Warteschlange für Anwendungsvorgänge

Während die manuelle Installation von Produkten aus Alle Anwendungen in die Warteschlange gestellt wird, wird die manuelle Installation einer Anwendung aus UIs wie Alle Anwendungen oder Application Manager nicht in die Warteschlange gestellt.

Manchmal empfängt die Instanz viele CICD-Anforderungen, reiht sie in die Warteschlange und verarbeitet sie, was dazu führen kann, dass die manuelle Installation über die Benutzeroberfläche nach der Aktualisierung der instanzweiten Sperre/des Mutex sucht. In diesem Fall kann der Administrator die Warteschlange für Anwendungsvorgänge vorübergehend anhalten.

Administratoren können die Warteschlange für Anwendungsvorgänge über die UI-Seite „Systemdiagnose->Warteschlange für Anwendungsvorgänge“ verwalten. Im Bereich „Status der Vorgangswarteschlange“ kann der Administrator die Warteschlange anhalten oder fortsetzen. Der Administrator kann auch den Tracker für ausstehende Ausführungen abbrechen. Dadurch wird die entsprechende Nachricht in der Warteschlange durch den Auftrag zur Überwachung der App-Vorgangswarteschlange aus NowMQ entfernt.

UI-Seite der Anwendungsvorgangswarteschlange

Beispiel für die UI-Seite der Anwendungsvorgangswarteschlange. Der Administrator kann auf die Schaltfläche in „Status der Vorgangswarteschlange“ klicken, um die Warteschlange anzuhalten oder fortzusetzen.

Klicken Sie auf das Listenelement „Ausführungstracker für Anwendungsvorgänge“, um das Formular „Ausführungstracker“ zu öffnen. Wenn die Nachricht in der Warteschlange aussteht, aktualisieren Sie den Status der Ausführungsnachverfolgung auf „Abgebrochen“. Durch Speichern der Änderung wird die entsprechende CICD-Anforderung in der Warteschlange abgebrochen. Hinweis: Wenn der Status des Ausführungstrackers „Wird ausgeführt“ lautet, kann die CICD-Anforderung nicht abgebrochen werden.

Warteschlange für Anwendungsvorgänge und Upgrade-Zeitfenster

Standardmäßig beendet die Warteschlange für Anwendungsvorgänge 2 Stunden (kann über die Sys-Eigenschaft „com.glide.update_operation.queue_upgrade_window“ angepasst werden) vor dem geplanten Upgrade die Verarbeitung von Nachrichten in der Warteschlange.

Der Status der Anwendungsvorgangswarteschlange wird in „Upgrade angehalten“ geändert. Während dieses Upgrade-Zeitfensters werden neue CICD-Anforderungen weiterhin in die Warteschlange gestellt.

Nach Abschluss des Upgrades nimmt die Warteschlange für Anwendungsvorgänge die Verarbeitung der Nachrichten in der Warteschlange automatisch wieder auf.

Auswirkung auf die CICD-Pipeline

Die vorhandenen Anforderungs-/Antwortverträge für die CICD-APIs werden nicht geändert. Der Vorgangsfehler aufgrund von instanzweiten Sperren-/Mutex -Konflikten, die in einem Release vor Tokyo beobachtet wurden, wird nicht angezeigt. Die Anforderung wird in die Warteschlange gestellt und je nach Auftragstyp nacheinander oder parallel bedient.

CICD-APIs, die Warteschlangen unterstützen

Die folgenden CICD-APIs werden zur Verarbeitung in die Warteschlange gestellt.

• api/sn_cicd/app_repo/install
• api/sn_cicd/v1/app_repo/install
• api/sn_cicd/v2/app_repo/install
• api/sn_cicd/app_repo/rollback
• api/sn_cicd/v1/app_repo/install
• api/sn_cicd/v2/app_repo/rollback
• api/sn_cicd/sc/apply_changes
• api/sn_cicd/v1/sc/apply_changes
• api/sn_cicd/v2/sc/apply_changes
• api/sn_cicd/app/batch/install
• api/sn_cicd/sc/import
• api/sn_cicd/plugin/{plugin_id}/activate
• api/sn_cicd/plugin/{plugin_id}/rollback

Anwendungsinstallationen und Plugin-Aktivierungen parallelisieren

Ab Tokyokönnen die folgenden Vorgänge parallel zu anderen Vorgängen ausgeführt werden.

• api/sn_cicd/app_repo/install
• api/sn_cicd/v1/app_repo/install
• api/sn_cicd/v2/app_repo/install
• api/sn_cicd/plugin/{plugin_id}/activate

Die gesamte Warteschlangenverarbeitung übernimmt eine instanzweite Sperre/einen Mutex und hält diesen Mutex, bis ein Vorgang in der Warteschlange abgeschlossen ist. Diese Sperre heißt UpdateMutexund ihr Status kann in der Tabelle sys_mutex angezeigt werden. Während dieser Zeit können Vorgänge, die dieselbe Sperre verwenden (App-Installationen, Plugin-Aktivierungen, Quellcodeverwaltungsvorgänge), nicht über die Benutzeroberfläche ausgeführt werden. Die Warteschlange kann weiterhin über die Seite „Warteschlange für Anwendungsvorgänge “ angehalten werden, um die Sperre freizugeben, nachdem derzeit ausgeführte Aufträge abgeschlossen wurden.

Die Parallelisierung ist standardmäßig aktiviert. Sie kann mithilfe der Eigenschaft com.glide.update_operation.parallel_operation_enabled deaktiviertwerden, und alle Vorgänge werden wie in früheren Releases nacheinander aus der Warteschlange ausgeführt.

Grenzwerte für Parallelisierung

Der Warteschlangenprozessor bestimmt, ob ein Auftrag in der Warteschlange ausgeführt werden kann. Wenn ein Job ausgeführt werden kann, wird er bei erster Verfügbarkeit von einem Instanzknoten übernommen. Wenn nicht, wird er an die Warteschlange zurückgegeben, und der Prozessor wertet den nächsten Auftrag in der Warteschlange zur Verarbeitung aus.

Es gibt ein Limit für die maximale Anzahl von Jobs, die parallel ausgeführt werden können. Der Standardwert ist 2. Diese Eigenschaft kann über glide.update.app_operation_queue.parallel.max umgeschaltet werden. Beachten Sie jedoch, dass es eine Obergrenze für verfügbare Threads gibt , um die Installation auszuführen, und eine erhöhte Parallelisierung erfordern zusätzlichen Arbeitsspeicher, der die Instanz für aktive Benutzer verlangsamen kann.

Ressourcensperren werden abgerufen

Die folgenden Plugins und Anwendungen können nicht parallel installiert werden.

• Zwei beliebige Vorgänge, die denselben Bereich verwenden, einschließlich Anpassungen.
• Zwei beliebige Vorgänge, die Schemaänderungen verursachen.
• Zwei beliebige Vorgänge, die Korrekturskripts enthalten.

Die Warteschlangenverarbeitung bestimmt, ob diese Kriterien für Vorgänge in der Warteschlange erfüllt sind, und stellt gegebenenfalls nicht verarbeitbare Aufträge zurück. Die Fortschritts-ID des Auftrags wird aktualisiert, um anzugeben, ob der Vorgang darauf wartet, dass entsprechende Ressourcensperren abgerufen werden. Ein ausgeführter Vorgang verwaltet eine Liste der Ressourcen (Bereiche, Schema, vorhandene Korrekturskripts) in der Tabelle sys_padlock, und das Einfügen und Freigeben dieser Sperren kann in dieser Tabelle anhand der Fortschritts-ID beobachtet werden. Wenn ein Job in der Warteschlange zurückgestellt wird, weil die erforderlichen Ressourcensperren nicht abgerufen werden können, wird er in eine Abkühlphase versetzt, damit andere Nachrichten verarbeitet werden können. Die Abkühlzeit kann mit der Eigenschaft com.glide.update_operation.job_cancel_timeout_minutesgeändert werden. Die Aufgabe befindet sich noch in der Warteschlange und wird auf der Seite „Warteschlange für Anwendungsvorgänge “ angezeigt.

Wenn die Warteschlange nicht in der Lage ist, ein Anwendungspaket herunterzuladen oder ein Plugin zu finden, um nach den erforderlichen Ressourcen zu suchen, wird ein Fehler für diesen Vorgang in der Warteschlange protokolliert. Wenn der Vorgang eine bestimmte Anzahl von Vorschauen seiner Ressourcen nicht anzeigt, schlägt der Tracker fehl, und der Auftrag wird aus der Warteschlange entfernt. Die maximale Anzahl ist standardmäßig auf 3 festgelegt und kann durch die Eigenschaft com.glide.update_operation.max_failure_count geändert werden.

Hinweis:

Wenn die erforderlichen Sperren nicht abgerufen werden, gilt dies nicht als Fehlerversuch. Nur aufgetretene Fehler, z. B. Fehler beim Herunterladen eines Anwendungspakets aus der AppRepo-Anzahl.