Probleme beim asynchronen Nachfordern (mehrfache Archivierung)
Bei den Tests zu #13 (closed) und #16 (closed) ist ein weiterer Fehler aufgefallen.
Nachgeforderte Daten werden aktuell ähnlich wie online empfangene Daten verarbeitet, landen also erstmal in einer Queue bevor sie irgendwann archiviert werden. Problematisch ist das Verhalten, wenn mehrfache ähnliche Nachforderungsaufträge direkt hintereinander (oder gleichzeitig) gesendet werden, z. B. über die Methode ArchiveRequestManager#request(ArchiveQueryPriority, List<ArchiveDataSpecification>)
, die als zweiten Parameter eine Liste von Nachforderungsaufträgen akzeptiert.
In diesem Fall fragt der erste Nachforderungsauftrag die nachzufordernden Daten an, die dann in der Nachforderungsqueue landen um demnächst in Containerdateien geschrieben zu werden. Der zweite Nachforderungsauftrag analysiert gleichzeitig erneut die Containerdateien und stellt (falls der Archivierungstask nicht schnell genug war) dieselben Datenlücken fest, wie der erste Nachforderungsauftrag, fordert diese also erneut an. Das führt dazu, dass die Daten schlussendlich doppelt nachgefordert werden und mehrfach in Container eingetragen werden, was kein erwartetes Verhalten ist.
Archivanfragen auf diese Daten liefern die Datensätze dann doppelt/mehrfach zurück.
Zur Problemlösung könnte es Sinn machen, dass sich das Archivsystem bereits erfolgreich nachgeforderte Datenbereiche irgendwie merkt. Hierzu könnte wie in #13 (closed) Stichpunkt 3. die Gap-Datei erweitert/ersetzt werden. Alternativ könnte das Archivsystem doppelte Daten bei Archivantworten unterdrücken (was aber nicht den mehrfachen Speicherverbrauch behebt, aber schon bei fehlerhaft nachgeforderten Daten das Problem umgehen würde). Weitere Lösungen wären denkbar, z. B. dass das Archivsystem keine Archivierungs-Queue beim Nachfordern verwendet sondern bei einem Nachforderungsauftrag erstmal alles vollständig archiviert (in Dateien schreibt) bevor es den nächsten Auftrag anfängt.