Wichtig
Detail
Wichtig
Detail
TL-Sync erkennt doppelte Nachrichten und überspringt diese automatisch. Fehlende Nachrichten werden bisher nicht erkannt und können zu komplizierten fachlichen Problem führen.
Verbesserung
TL-Sync soll erkennen, wenn eine Nachricht fehlt. Daraufhin soll es den Empfang anhalten, einen Fehler ins Log schreiben und die Monitor-Sicht soll das anzeigen.
Umsetzung
TL-Sync überträgt in jeder Nachricht die Revision des sendenden Systemes. Allerdings überträgt es nur die relevanten Revisionen. Diese Nummern sind also nicht lückenlos. Wird aber zusätzlich entweder die Nummer der zuletzt gesendeten Revision übertragen, oder die erste nicht gesendete Revision, dann liegen dem Empfänger genug Daten vor um diese Situation zu erkennen.
Fachlicher Hintergrund
TL-Sync verwendet Kafka. Und das garantiert eigentlich, dass keine Nachrichten verloren gehen. Daher wäre dieses Feature eigentlich unnötig. Leider kommt es aber bei Kunden immer wieder vor, dass Kafka falsch konfiguriert oder administriert wird. Dadurch kommt es zum Datenverlust und daraufhin zu fachlichen Problemen, die teilweise nur sehr schwer behoben werden können, bei denen der Kunde aber gleichzeitig großen Druck ausübt, diese innerhalb kürzester Zeit zu beheben. Daher ist dieses Feature leider doch sinnvoll.
Erkennen dieser Situation
Auf der Monitor Seite der Anwendung steht für TL-Sync receiver eine Zeile mit folgender Meldung:
Failed.
Cause: Processor class com.top_logic.kafka.knowledge.service.importer.KBDataProcessor failed.
Cause: LOG MARK: 'in-tl-sync-context' = 'true'.
Cause: Detected that messages are missing, when receiving changeset 12. The last processed changeset was 7. But the new message states that the last processed changeset should have been 9.
Korrektur dieser Situation
Die sendende Anwendung muss die fehlenden Daten erneut übertragen. Sie kann auch einfach alles neu übertragen. TL-Sync wird die bereits verarbeiteten Revisionen erkennen und überspringen.
Bevor die sendende Anwendung ihre Daten erneut schickt, müssen alle "zu neuen" Revisionen aus Kafka entfernt werden. Üblicherweise können alle noch vorhandenen Daten in Kafka gelöscht werden. Anwendungen mit "Chunking" müssen zusätzlich ihre gespeicherten Chunks löschen.
Code Migration
Hintergrund
- Das TL-Sync Nachrichten Format ändert sich durch diese Umstellung.
- Der aktualisierte Empfänger kann auch alten Nachrichten verarbeiten. Aber alte Empfänger können die neuen Nachrichten nicht verarbeiten und loggen Fehlermeldungen.
- Der Sender kann konfiguriert werden, um weiterhin Nachrichten des alten Typs zu senden. Wenn das gemacht wird, funktioniert aber auch die Erkennung fehlender Nachrichten nicht. Sie ist dann abgeschaltet.
- Wenn Nachrichten des neuen Typs verschickt werden, müssen auch alle empfangenden Anwendungen darauf umgestellt werden. Sonst scheitert der Empfang und loggt Fehlermeldungen.
Notwendige Migration
- Entweder müssen alle empfangenden Anwendungen gleichzeitig auf die neue Version aktualisiert werden.
- Oder alle sendenden, aktualisierten Anwendungen müssen konfiguriert werden, Nachrichten des alten Typs zu verschicken. Siehe dazu: ChangeSetSerializer.Config.getMessageVersion()
Test
Vorbereitung
- ZooKeeper, Kafka und TL Kafka Demo starten.
- Ein Objekt anlegen, damit eine Nachricht verschickt wird.
- Das initialisiert die Übertragung. Dadurch speichert sich der Empfänger, welche Revision er zuletzt empfangen hat.
Dafür sorgen, dass ein Changeset verloren geht
- Einen Haltepunkt im Consumer setzen, damit keine Nachrichten mehr empfangen werden können. Zum Beispiel am Anfang von: ConsumerDispatcher.poll(int, int)
- Ein weiteres Objekt anlegen, um eine weitere Nachricht zu verschicken.
- Die Anwendung beenden, ohne den Consumer diese Nachricht konsumieren zu lassen.
- Kafka und ZooKeeper beenden.
- Die Daten von ZooKeeper und Kafka im "tmp" Ordner löschen.
- Wo der liegt, kommt auf das Betriebssystem drauf an.
- ZooKeeper, Kafka und TL Kafka Demo wieder starten.
Prüfen, dass die Übertragung angehalten ist
- Ein weiteres Objekt anlegen, um eine weitere Nachricht zu verschicken.
- Dieses Objekt darf nicht ankommen. Auf der Monitor Seite muss für den TL-Sync Empfänger angezeigt werden, dass es ein Problem gibt.
Übertragung wiederherstellen
- Den tl:KBDataProducerTask in der SchedulerGui anhalten.
- TL Kafka Demo, Kafka und ZooKeeper beenden.
- Die Daten von ZooKeeper und Kafka im "tmp" Ordner löschen.
- ZooKeeper, Kafka und TL Kafka Demo wieder starten.
- In der Datenbank Tabelle TL_PROPERTIES die Einträge vom Sender löschen:
{{{#!sql delete from TL_PROPERTIES where "propKey" like 'TLSync.lastSentRevisionAtDate%' }}}
- Den tl:KBDataProducerTask in der SchedulerGui weiterlaufen lassen.
Prüfen, dass die Übertragung wieder funktioniert
- Prüfen, dass die beiden fehlenden Objekte nach spätestens 15 Sekunden angekommen sind.
- Falls die Anwendung nicht beendet wurde, während die Kafka Daten gelöscht wurden, kann es bis zu 11 Minuten dauern. Denn dann läuft weiterhin der Exponential Backoff, der denn erneuten Versuch des Empfangens ausbremst, um das Log nicht zu überfluten.