Beim regulären Stop des Lobster Integration Servers werden Jobs, die zu diesem Zeitpunkt noch laufen, zu Ende geführt. Der tatsächliche Stop des Servers wird also so lange verzögert, bis diese Jobs beendet sind. Sobald der Stop ausgelöst wurde, werden aber keine neuen Jobs mehr gestartet.

In bestimmten Fällen, z. B. bei sehr lange laufenden Profilen oder wenn in Phase 6 das Zielsystem nicht mehr antwortet, kann es vorkommen, dass ein einzelnes Profil sehr lange läuft. In diesem Zustand ist kein erneuter Start des Integration Servers möglich. In dieser Situation muss der Administrator entscheiden, ob er den Stop (in verschiedenen Varianten) erzwingt. Siehe Abschnitt Control Center → System → Einstellungen.

Der Anwender ist selbst dafür verantwortlich, dass beim Erzwingen des Stops keine relevanten Verarbeitungsprozesse mehr laufen, sondern nur noch lang dauernde oder hängengebliebene Cron-Operationen. Andernfalls kann ein Verlust der Daten, die aktuell bearbeitet werden, nicht vollständig ausgeschlossen werden.

Ein Start des Integration Servers muss unbedingt vermieden werden, solange der alte Prozess noch nicht vollständig beendet ist, weil er zu einen nicht konsistenten Zustand des Systems führen kann. Siehe auch Abschnitt Automatisches Beenden eines unvollständig gestarteten Integration Servers or Lobster Integration. Da Netzwerkverbindungen nach Beenden des Prozesses auf Systemebene für einige Sekunden verweilen können, ist eine kurze Wartezeit vor einem neuen Start empfohlen.

Crashed Jobs

Siehe auch Abschnitt Vorhaltezeit von Backup-Dateien, Logs, Crashed Jobs.

Wenn ein Job durch erzwungenen Abbruch nicht zu Ende kommt, wird er als "Crashed Job" markiert. Bei einem anschließenden Neustart von Lobster Integration werden alle Crashed Jobs neu gestartet. Die Abarbeitung beginnt dann nicht an der Stelle des Abbruches, sondern wieder ganz von vorne. Falls der Abbruch nach Phase 3 erfolgte, wurden alle Funktionen bereits ausgeführt, insbesondere auch die autonumber-Funktionen (autonumber(a), autonumber(a,b,c), autonumber-system-wide(a), autonumber-system-wide(a,b,c)) und Datenbankoperationen in Funktionen. Bei der Implementierung der Profile ist es daher in der Verantwortung des Entwicklers/Anwenders, die Möglichkeit eines Crashs zu berücksichtigen und die möglichen Auswirkungen einer erneuten Ausführung für den Prozess zu bewerten.

Zu einem Crashed Job kann es auch bei einem Rechnerabsturz, Hardwarefehler, Stromausfall, usw. kommen. In diesem Fall werden die Crashed Jobs ebenfalls nach einem Neustart wieder begonnen.

Funktionsweise von Lobster Integration für crashed Jobs:

Voraussetzung ist dass in der Konfigurationsdatei ./etc/startup.xml der Parameter trackCrashedJobs auf true steht.
Lobster Integration wird dann bei jedem Jobstart eine Datei im Verzeichnis ./datawizard/backup/lock anlegen.
Die angelegte Datei wird wieder gelöscht wenn ein Job erledigt ist. Unabhängig davon, ob erfolgreich oder nicht erfolgreich beendet wurde.
Die Datei heißt <Jobnummer>.lck und ist mit einem Texteditor lesbar.
Enthalten ist unter anderem die Jobnummer, der Name der Eingangsdatei und die ID (nicht der Name) des zugehörigen Profils.
Die Datei enthält nicht die originalen Nutzdaten. Folglich muss für einen Neustart des Jobs die Backupdatei des Jobs noch vorhanden sein.
Sind Crashed Jobs vorhanden, die Backups noch existent und das Feature aktiviert, wird nach einer einstellbaren Zeit (restoreWaitTime in ./etc/startup.xml) begonnen die Jobs neu zu starten.
In den Detail-Logs im Control Center ist vermerkt, dass es sich um einen Neustart eines Crashed Jobs handelt.
Ist das Feature nicht aktiviert, wird bei Crashed Jobs nur noch ein Eintrag in der Datenbank-Tabelle dw_log_sum für jeden gecrashten Job vorgenommen, damit dieser für die Benutzer sichtbar ist.

In einem Produktivsystem sollte die Häufigkeit solcher Crashed Jobs durch Stabilisierung der Systemumgebung auf ein Minimum reduziert werden.

Siehe auch Bereiche Einstellungen, Force Stop und Emergency Halt per HTTP auslösen und Konfiguration des Abbruchverhaltens in ./etc/startup.xml.

Neustart von Crashed Jobs verhindern

Um einen Neustart aller Crashed Jobs zu verhindern, kann der Parameter startCrashedJobs in der Konfigurationsdatei ./etc/startup.xml verwendet werden.

Wenn Sie den Neustart einzelner Crashed Jobs verhindern wollen, können Sie im Unterordner lock des Backup-Verzeichnisses nach Dateien mit Namen <Jobnummer>.lck suchen und dieses selektiv löschen. Der Default-Wert für das Backup-Verzeichnis ist ./datawizard/backup, siehe Parameter backupDir in der Konfigurationsdatei ./etc/startup.xml.

Mit dem Parameter ignoreOldCrashedJobs können Sie den Neustart von Crashed Jobs verhindern, die älter als eine bestimmte Anzahl an Tagen sind.