Beim Export in P wurde neben einem DriverTimeoutException-Fehler auch folgender Fehler gemeldet, der mir bisher noch nicht untergekommen ist.

In Q1 war der Export dagegen fehlerfrei durchgelaufen.

WriteTimeoutException: Cassandra timeout during SIMPLE write query at consistency LOCAL_QUORUM (2 replica were required but only 1 acknowledged the write)”

Die WriteTimeoutException mit unterschiedlichen Folgefehlern entsteht, wenn zu große Datenmengen gleichzeitig ins Cassandra-Cluster geschrieben werden. Der Treiber in den Spark Apps meldet dann, dass das Cluster mit den zu schreibenden Daten überfordert ist und meldet, dass die Verbindung abgebrochen ist. Die Gegenstelle im Cluster ist dann für die Spark App nicht mehr erreichbar, daher folgt eine HeartbeatException. Der Treiber in der Spark App löst dann allgemein eine DriverTimeoutException aus.

Ingest-Button reagiert nicht

• Regelmäßiger Neustart der Komponenten:
  würde mehr Instabilität reinbringen, denn das Admin-Backend steuert die Ladeprozesse.
• Admin-Backend nicht mehr eigene Threads verwalten lassen, da das mit den von Grifana verwalteten Threads in die Quere kommt.

404-Fehler bei Aufruf von Institutionenseiten sowie 500-Fehler bei Aufruf von Datenbeständen in Dash

• Automatischer Neustart des SOLR
  Da dieser SOLR in 7 Jahren Betrieb jetzt das erste Mal ausgefallen ist, bestand bisher nicht die Notwendigkeit.

Prozess scheint zu hängen

• Es kann sein, dass ein Prozess länger benötigt, insbesondere bei großen Zeitungsingrest, großen Datenmengen oder wenn auf vorherige Prozesse gewartet werden muss.

• In Dash anzeigen, ob relevante Systeme arbeiten

Im Report zu den Binaries sind 429-Fehler. 

Limitierung durch Datenpartner

GeneralDataException: Couldnt get Data from url http://ddb-p1-vmlbp01.fiz-karlsruhe.de:8022/abcde/xxrdqfv4ym4whi74wxopi5lidziv5m3r/Eich_IX_61_3.jpg, status: 404

Bei der Transformation kann nicht auf die entzippten Binaries zugegriffen werden.
Mögliche Ursachen:

• Datei existiert nicht
• Pfad zur Datei fehlerhaft
• Binaries Service ist prinzipiell nicht erreichbar
• Aufgrund von Netzwerkstörung kann nicht auf die abgelegten Binaries zugegriffen werden

Prüfen:

• Die Lieferung der Binaries hat funktioniert (Dateigröße stimmt mit der der Originaldatei überein)
• Pfad und Dateiname in den Metadaten stimmt mit der Ablage der mitgelieferten Binaries überein (Dateiname, Pfad). Dabei insbesondere auf Leerzeichen und Sonderzeichen prüfen

warten

FIZ kann prüfen:
Queue vorhanden?
BS läuft?

Nutzern im Report den Status der Queue des BS anzeigen

FIZ:
Local Binaries Provider neu startenIngest-Button reagiert nicht

Reports zu Export, Index, etc. nicht mehr vorhanden

FIZ:
Neustart Dash-Backend

XsltTransformationException: Error evaluating ((attr{position=...}, ...)) on line 85 column 40 of binaries.xsl:: HTTP 500 Internal Server Error at template create_binary on line 29 column 40 of binaries.xsl: invoked by xsl:call-template at jar:file:/data/storage/logs/spark/worker/app-20230803142938-0472/0/./ddb-mapping-new-4.21.jar!/xsl/lido/binaries/binaries.xsl#407 invoked by xsl:for-each at jar:file:/data/storage/logs/spark/worker/app-20230803142938-0472/0/./ddb-mapping-new-4.21.jar!/xsl/lido/binaries/binaries.xsl#68 In template rule with match="/" on line 66 of binaries.xsl

FIZ:
Konfiguration der SparkApps prüfen
BS läuft?

Reports zu Export, Index, etc. nicht mehr vorhanden

UnknownHostExceptions beim Zugriff auf das Cluster und den AAS 

FIZ:
evtl. Neustart Dash-Backend

SocketTimeoutException: Read timed out

http://d-nb.info/gnd/6031336-5

Der Fehler kann ignoriert werden. Bei erneuter Prozessierung sollte der Report wieder vollständig sein.

Exception: Failed to parse ZDB Entry for 3173082-6. Could not extract location and language: NullPointerException: 

Während der Prozess lief, hat es einen knapp eine Minute andauernden Ausfall des Solr Servers gegeben

Erneut indexieren ohne erneute Transformation

Bzw. "Wenn ich das richtig in Erinnerung habe, dann führt Fehlermeldung "Exception: Failed to parse ZDB Entry for 3181871-7. Could not extract location and language: NullPointerException:") tatsächlich "nur" dazu dass die entsprechenden Informationen fehlen, die Ausgaben aber trotzdem indexiert sind. Hier lohnt sich ein Neuindexieren in Q1 nicht, wenn sicher ist, dass es kein Problem mit den ZDB-Daten gibt. Das Laden in Q1 dient ja lediglich der Abnahme der Daten und wenn bereits andere Daten mit denselben ZDB-IDs erfolgreich geladen wurden, dann bringt ein Neuindexieren keinen Erkenntnisgewinn. "

Beim Export in P wurde neben einem DriverTimeoutException-Fehler auch folgender Fehler gemeldet, der mir bisher noch nicht untergekommen ist.

In Q1 war der Export dagegen fehlerfrei durchgelaufen.

WriteTimeoutException: Cassandra timeout during SIMPLE write query at consistency LOCAL_QUORUM (2 replica were required but only 1 acknowledged the write)”

Die WriteTimeoutException mit unterschiedlichen Folgefehlern entsteht, wenn zu große Datenmengen gleichzeitig ins Cassandra-Cluster geschrieben werden. Der Treiber in den Spark Apps meldet dann, dass das Cluster mit den zu schreibenden Daten überfordert ist und meldet, dass die Verbindung abgebrochen ist. Die Gegenstelle im Cluster ist dann für die Spark App nicht mehr erreichbar, daher folgt eine HeartbeatException. Der Treiber in der Spark App löst dann allgemein eine DriverTimeoutException aus.

Als Lösung wäre hier möglich, einige Einstelllungen in den Spark Apps zu verändern, damit sich die Schreibgeschwindigkeit auf das Cassandra-Cluster verringert.

In Produktion nur gut 100.000 Ausgaben von der SLUB. Vor dem Ingest hatten wir ca. 400.000.
Laufender Prozess nicht mehr unter "Prozesse" gelistet.

Ein paar Tage später sind die Objekte da!

Der Ausgabenindexierungsprozess für dieses große Dataset hat so lange gedauert, dass der Prozessmonitor in Dash, der den ganzen Ablauf der Ingestierungspipeline regelt, den Kontakt zu dem Prozess verloren hat... Deshalb gibt es keinen Bericht und deshalb habt ihr falsche Zahlen erhalten als der Prozess aus eurer Sicht fertig war. Tatsächlich lief er aber noch 2 Tage weiter. 

Fehler mit der Meldung "WstxEOFException: Unexpected EOF in prolog at [row,col \{unknown-source}]: [1,0]".

WstxEOFException: Unexpected EOF in prolog at [row,col {unknown-source}]: [1,0]

Diese Meldung deutet immer auf ein fehlendes oder leeres Alto hin. Das passt ja auch zu den Binaries Fehlermeldungen. Das sind die Ausgaben die nicht indexiert wurden. Auch hier bringt eine erneute Indexierung ohne Transformation nichts, denn das Herunterladen der ALTOs wir nur bei der Transformation getriggert und macht hier sowieso erst Sinn, wenn der Fehler beim Datengeber behoben ist. 

Das Bild war beim Herunterladen kaputt.

FIZ:
Herunterladen des Bildes muss erneut angestoßen werden.

Im Portal sind weniger DS vorhanden als in Dash angezeigt werden. In Q1 dagegen hat die Dash-Anzahl mit der Portal-Anzahl übereingestimmt.

Solr-Replikation hat nicht funktioniert

Auf nächste Replikation warten

PDFs werden zwar vom Medienviewer angezeigt, man kann sie aber nicht öffnen. In dash gibt es keine Binary-Fehler.

In den Daten werden keine PDFs geliefert, sondern .jpg.

Da aber in lido:resourceType/lido:term=text geliefert wird, wird davon ausgegangen, dass es sich um PDFs handelt.
Das passt nicht zusammen.
Wenn nur .jpg geliefert werden, müsste der Medientyp der Binaries "image" sein.

Der Medientyp des Objektes kann trotzdem "Text" sein.

Medientyp bei den gelieferten Binaries anpassen, nicht bei Art des Mediums des gelieferten Objekts.

Fehlerhafte Objekte bei Ingest in q1

UnavailableException: Not enough replicas available for query at consistency LOCAL_QUORUM (2 required but only 1 alive)

Speicherplatt ist vollgelaufen

Zeitungsportal-Daten Anzeige in Q1 liefert internen Serverfehler

Neustart Q1 Frontend

Zeitungsportal:
Anzahl X von Zeitungsausgaben wurde nicht indexiert.

Probleme bei der Übermittlung der ALTO-URLs an den Binaries Service.

Neue Revision erstellen, Dataset wird neu transformiert, dann ingestieren. 

Diskrepanz zwischen der Anzahl der Suchergebnisse in der regulären DDB-Suche und im Zeitungsportal

lässt sich immer mit Fehlern bei der Indexierung erklären. Es gibt die "normale" Indexierung die den Suchindex für das Hauptportal aufbaut und die Ausgabenindexierung die die Daten in den Suchindex für das Zeitungsportal schreibt. Wenn in einem der Schritte Fehler auftauchen, können die Daten in dem entsprechenden Index fehlen. 

Logos der Institutionen werden nicht aktualisiert

Fehlender Parameter bei einem der beiden Binaries-Aufrufe im Mapping

Mapping korrigieren

Logo einer Institution oder Bild eines Objektes erscheint schwarz bzw. mit schwarzem Hintergrund oder falscher Hintergrundfarbe (Binaries werden invertiert dargestellt)

Transparenz in der Bilddatei

Logo als Jpeg hochladen