Export von Hierarchien in paralleler Ausführung

[BartChris]

Der asynchrone Export von zahlreichen Vorgängen, insbesondere bei Zeitungsvorgängen, führt aktuell häufiger zu Problemen.
Beim Export von Zeitungsvorgängen mit mehreren Threads kann es vorkommen, dass parallele Exportvorgänge in denselben Ordner schreiben oder einen Ordner löschen in den gerade geschrieben wird, was zu Konsistenz-Problemen und Java-Fehlern führt.

Verantwortlich dafür sind vermutlich insbesondere parallele Zugriffe auf Ordner und Dateien im Dateisystem.

kitodo-production/Kitodo/src/main/java/org/kitodo/export/ExportDms.java

Line 229 in e8a9c78

if (!fileService.delete(exportFolder)) {

Diese Probleme können dadurch minimiert werden, dass in der Kitodo-Config taskManager.autoRunLimit =1 gesetzt wird. Dadurch wird nur ein Thread parallel gestartet. Parallele Schreibvorgänge finden so nicht mehr statt, was dadurch bedingte Fehler ausschließt, aber zu einem geringeren Durchsatz beim Export führt.

Leider ist die Exportlogik sehr komplex, kann von vielen Orten gestartet werden und ist von verschiedenen Variablen abhängig. Änderungen an einer Stelle können daher zu Problemen an anderer Stelle führen.
#6625 (review)

An dieser Stelle daher nur eine erste vorsichtige Überlegung, die darauf basiert, beim Export z.B. von Zeitungsausgaben zu verhindern, dass dieselbe Überordnung(en) immer wieder und aus mehren Export-Threads heraus geschrieben wird. Statt also die Überordnung mit jedem Kind-Vorgang erneut zu exportieren, böte es sich an, die zu exportierenden Vorgänge zunächst zu sammeln, und dann getrennt nach Hierarchielevel nur einmalig zu exportieren.
Die Grundvoraussetzung dafür ist, dass jeder Vorgang einen eindeutigen Exportordner erhält, so dass garantiert ist, dass kein paralleler Zugriff auf denselben Ordner erfolgt. Evtl. gibt es Umgebungen in denen das nicht zutrifft.

Die Logik sähe dann in etwa so aus:

private void exportDMSForProcesses(List<Process> processes) {
    ExportDms export = new ExportDms();

// Wir sammeln alle Vorgänge in einem LinkedHashSet, dass garantiert, 
//dass jeder Vorgang nur einmal vorhanden ist und
// nicht etwa die selbe Überordnung der Zeitungsausgaben mehrmals.
    Set<Process> allToExport = new LinkedHashSet<>();
    for (Process p : processes) {
        allToExport.add(p);
        allToExport.addAll(getAllParents(p));
    }

// Wir sortieren alle gesammelten Vorgänge nach der Hierarchieebne.
// Dies garantiet, dass die Kindvorgänge zuerst exportiert werden. Danach werden
// die jeweiligen Elternvorgänge  exportiert.
    List<Process> ordered = new ArrayList<>(allToExport);
    ordered.sort(Comparator.comparingInt(this::getHierarchyDepth).reversed());

// Wir exportieren alle Vorgängen in Reihenfolge. Elternvorgänge werden nur 
// einmal exportiert, da sie nur einmal in der Liste vorhanden sind.
    for (Process p : ordered) {
        try {
            export.startExport(p);
        } catch (DataException e) {
            Helper.setErrorMessage(
                "errorExporting",
                new Object[]{ObjectType.PROCESS.getTranslationSingular(), p.getId()},
                logger,
                e
            );
        }
    }
}

private Set<Process> getAllParents(Process process) {
    Set<Process> parents = new LinkedHashSet<>();
    Process current = process.getParent();
    while (current != null) {
        parents.add(current);
        current = current.getParent();
    }
    return parents;
}

private int getHierarchyDepth(Process process) {
    int depth = 0;
    Process current = process;
    while (current.getParent() != null) {
        depth++;
        current = current.getParent();
    }
    return depth;
} 

Die Logik versucht eines der zentralen Probleme aktuell zu adressieren: Das parallele Schreiben in denselben Exportordner, ist aber nur als erster Vorschlag zu verstehen.

[henning-gerhardt]

Deine erste Idee ist gut, ich beschreibe aber mal die Situation aus der SLUB:

Exporte werden in aller Regel automatisiert und aus dem Workflow heraus gestartet. Dabei können diese aus diversen Projekten und unterschiedlichen Medientypen nacheinander oder mit sehr großen zeitlichen Abständen passieren. Vorgänge Zeitungsausgaben werden jeweils einzeln durch den Workflow exportiert, so dass es nie eine Liste von Zeitungsausgaben einer Zeitung in einem Jahr gibt. D.h. von Zeitung A und Jahrgang X werden M Ausgaben exportiert, dann von Zeitung B, Jahrgang Y N Ausgaben und dann dazwischen ein paar Bände aus Mehrbändigen Werken oder oder von periodischen Werken (Zeitschriften). Zwar überschreiben sich meistens nur die Hierarchien der Zeitungen, aber es kann auch vorkommen, dass beim Export von einer Mehrzahl an Bänden eines Werkes, die Werks-Hierarchie ebenfalls mehrfach geschrieben / überschrieben wird.

Darüber hinaus gibt es noch das Szenario, dass nach Metadaten-Korrekturen an vielen Vorgängen, diese Vorgänge ebenfalls exportiert werden müssen. Dies geschieht in aller Regel als administrativer Export (Aktionen -> Export DMS über die gewählte Treffermenge) aus der Vorgangsliste heraus. Diese Korrekturen und die damit durchgeführten Exporte für Zeitungen auf Jahres-Ebene sind für uns leider keine Lösung, da diese zu rekursiven Exporten führen, die exponentiell mit der Anzahl an Exporten wachsen und schlussendlich zum Absturz des Systems führen.

@andre-hohmann kann hier sicher noch weitere Szenarien ergänzen und ggf. meine aufgeschriebenen korrigieren, wenn sie Fehler enthalten.

[BartChris]

Ich verstehe, diese Form von "chaotischen" Exportszenarien legt für mich nahe, dass man zusätzlich zur oben vorgeschlagenen Reduzierung der Exportvorgänge mindestens alle Elternvorgänge durch einen Art Locking-Mechanismus (ConcurrentHashMap) blockiert, um zu verhindern, dass parallel in denselben Elternvorgang (bzw. dessen Export) geschrieben wird.

Darüber hinaus gibt es noch das Szenario, dass nach Metadaten-Korrekturen an vielen Vorgängen, diese Vorgänge ebenfalls exportiert werden müssen. Dies geschieht in aller Regel als administrativer Export (Aktionen -> Export DMS über die gewählte Treffermenge) aus der Vorgangsliste heraus. Diese Korrekturen und die damit durchgeführten Exporte für Zeitungen auf Jahres-Ebene sind für uns leider keine Lösung, da diese zu rekursiven Exporten führen, die exponentiell mit der Anzahl an Exporten wachsen und schlussendlich zum Absturz des Systems führen.

Dieses Verfahren würde zumindest davon profitieren, wenn man die Zahl der exportierten Elternvorgänge (nur einmaliger Export der Elternvorgänge) reduziert. Auch wenn es vermutlich noch andere Probleme gibt.

[andre-hohmann]

Ich kann @henning-gerhardt Ausführungen nicht ergänzen.

Es wäre hilfreich, wenn die Exporte der übergeordneten Vorgänge für die zugehörigen untergeordneten Vorgang zusammengeführt werden könnten - insbesondere für Zeitungsvorgänge.
Es sollten dafür natürlich keine weiteren Probleme erzeugt werden.
Der Export der Hierarchien ist komplex und am Ende muss sicher gestellt werden, dass immer die aktuellste Version mit allen Referenzen zu den untergeordneten Vorgängen exportiert wird.

[M3ssman]

Ein komplett anderes Szenario ist an der ULB Sachsen-Anhalt im Einsatz.

Anstelle von Kitodo.Presentation wird ein DSpace-basierts Repositorium verwendet. Die DMS-Exportdaten müssen aufbereitet werden, damit ein Artefakt im SAF-Format rauskommt. Wir haben eine zusätzliche (Post-DMS) Exportkomponente erstellt, die den Export-Hotfolder überwacht und bei Änderungen (=neues Verzeichnis erstellt) reagiert, in dem ein Worflow getriggert wird, der im Erfolgsfall ein SAF-Datenpaket an den eigentlichen Zielort im Netzwerk schickt.

Zeitungen werden bei uns i.d.R. Jahrgangsweise abgeschlossen (= exportiert) von einer einzigen Person. Durch den jahrgangsweisen Abschluss soll sichergestellt werden, dass der Jahrgang alle seine Ausgaben kennt, wenn es zum Export kommt.
Aktualisierungen der veröffentlichten Vorgänge gibt es nicht direkt, indirekt via Re-OCR.

In der Zusatzkomponente fallen auch die zusätzlichen Exporte der Überpordnungen auf. Allerdings vermeiden wir etwas Arbeit, in dem geprüft wird, ob der Vorgang bereits am finalen Zielort vorhanden ist. Ist dort schon ein Artefakt mit dem kalkulierten Namen, dann passiert nix. Bisher hatten wir einen zusätzlichen DMS-Export-Zielordner, wo zuerst die Vorgänge aus Kitodo gelandet sind, und wenn alle an Ort und Stelle waren, wurden dann alle Ordner per Hand in den Zusatzexport kopiert. Das hatte den Preis, dass die Daten zwischenzeitlich doppelt vorlagen.