Der Datenverteiler hat Probleme beim Zusammenfügen von Datentelegrammen
Bei Tests des neuen Archivsystems ist das folgende grundsätzliche Problem im Datenverteiler aufgefallen.
Wenn an eine Senke von mehreren Sendern gleichzeitig große Datensätze gesendet werden, kann es passieren, dass der Datenverteiler z. B. folgende Meldungen ausgibt und die Datensätze verwirft:
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Die Telegramme sind nicht in der richtigen Reihenfolge eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Die Telegramme sind nicht in der richtigen Reihenfolge eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Die Telegramme sind nicht in der richtigen Reihenfolge eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Ein mittleres Telegramm ist ohne erstes Telegramm eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Ein mittleres Telegramm ist ohne erstes Telegramm eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Ein mittleres Telegramm ist ohne erstes Telegramm eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Ein mittleres Telegramm ist ohne erstes Telegramm eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Ein mittleres Telegramm ist ohne erstes Telegramm eingetroffen: BaseSubscriptionInfo[...]
WARNUNG: Datenverteiler.de.bsvrz.dav.dav.main.TelegramAggregator
Das letzte Telegramm ist ohne vorherige Telegramme eingetroffen: BaseSubscriptionInfo[...]
Dieses Problem besteht grundsätzlich schon immer im Datenverteiler, jedenfalls mindestens seit 2003, damals aber noch mit weniger aussagekräftigen Fehler-Meldungen.
Die Senke ist in unserem Fall die Schnittstelle, mit der das Archivsystem Anfragen empfängt (die dann verworfen und nicht beantwortet werden), aber das Problem besteht allgemein unabhängig vom Archivsystem und könnte z. B. auch bei großen parallelen Konfigurationsanfragen auftreten.
Technische Details
Wenn große Nutzdatensätze verschickt werden sollen, teilt die sendende Applikation diese in mehrere Teiltelegramme einer bestimmten Maximalgröße auf. Der (Zentral-)Datenverteiler setzt diese wieder zusammen, vergibt einen Datenindex, zerlegt die Telegramme wieder in Teiltelegramme und verschickt diese an die Empfänger bzw. an die Senke.
Um zusammenhängende Datensätze einander zuzuordnen sind diese Teiltelegramme durchnummeriert. Außerdem enthält jedes Teil-Telegramm die Datenidentifikation des Datensatzes (Objekt, Attributgruppe, Aspekt, Simulationsvariante).
Der Zentral-Datenverteiler benutzt aktuell nur diese beiden Informationen um Telegramme zusammenzusetzen.
Für eine Quelle-Empfänger-Kombination ist das ausreichend, da es immer nur eine sendende Applikation (die Quelle) gibt und daher davon auszugehen ist, dass wenn diese die Telegramme in der richtigen Reihenfolge sendet, sie auch beim Datenverteiler richtig ankommen und zusammensetzbar sind.
Bei einer Sender-Senke-Kombination kann es jedoch mehrere Sender geben, und wenn zwei oder mehr Sender gleichzeitig zerstückelte Telegramme senden, dann kann sich der Empfang der Teiltelegramme beim Datenverteiler verzahnen, wodurch der Datenverteiler "durcheinander kommt", wer was gesendet hat, und diese nicht mehr richtig zusammensetzen kann.
Auswirkungen
Das Problem scheint bisher nur selten aufzutreten. Es ist untypisch, dass an Senken von mehreren Sendern gleichzeitig große Datenmengen gesendet werden, da typische Archiv- und Konfigurationsanfragen in den meisten Fällen so klein sind, dass sie nicht gesplittet werden müssen.
Lösungsidee
Ein offensichtlicher Workaround wäre, statt dem Tupel (Datenidentifikation/Teiltelegrammnummer) das Tripel (Datenidentifikation/Teiltelegrammnummer/Verbindung über die das Telegramm angekommen ist) zur Telegrammaggregation zu benutzen, aber das ist bei weiterer Betrachtung auch nicht korrekt, da einerseits der Datenverteiler mehrere Sender hinter Dav-Dav-Verbindungen nicht unterscheiden kann und andererseits auch die Datensätze von einem einzelnen Sender aufgrund von Ersatzverbindungen usw. (theoretisch) über verschiedene Verbindungen beim Datenverteiler eingehen können.
Eine bessere Lösung ist vermutlich durch Betrachtung des applikationsseitig generierten provisorischen Datenindexes und/oder Datenzeitstempels möglich, aber das müsste noch genauer analysiert werden