Auf dieser Seite werden Fehler in Dash-Prozessierungen, deren Ursache und Möglichkeiten zu deren Behebung dokumentiert. Sie soll als erste Informationsquelle dienen, falls Probleme auftreten.
NutzerInnen von Dash können damit evtl. erste Schritte autark übernehmen oder das Problem melden.
Entwickler können hier dokumentieren, welche Schritte zur Lösung eines Problems notwendig sind.

Es gab in der Vergangenheit bereits diese Seite, die nicht mehr gepflegt wurde: DDBdash Erklärungen für Log-Dateien/Fehlermeldungen

Evtl. kann man daraus Infos hierher übertragen.

Workflow

Falls ein Problem erkannt wurde, das nicht vom Dash-Nutzenden gelöst werden kann, bitte mit FIZ-Mapping-Team besprechen und evtl. nach Absprache ein Support-Ticket erstellen

Support-Tickets

Im JIRA-Projekt DDBTASK mit der Komponente "Support" erstellen.
Default-Assignee ist FIZ_MAPPING, sodass das Ticket zunächst geprüft und ergänzt werden kann bevor es an die Entwicklung weiter gegeben wird.

Fehlermeldungen und Erläuterungen

Bitte gerne ergänzen!

Dash-Oberfläche

Fehlerbeschreibung

Fehlercode/Log-Beispiel

Ursache

Behebung

weitere Infos für Entwickler

Optimierungsmöglichkeit

Ingest-Button reagiert nicht

FIZ:
Neustart Dash Frontend + Backend + Binaries Service

In einem Fall war das Admin-Backend zwar ansprechbar, aber alle Threads waren busy, sodass nur dessen Neustart geholfen hat. Alleine das Stoppen der Prozesse hatte 15 Minuten gedauert.

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

Ein Blick auf Icinga hat gezeigt dass der Solr Server nicht läuft

Neustart SOLR

DDBTASK-2646 - Getting issue details... STATUS

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.

Prüfen, ob Prozesse in Dash abgearbeitet werden
Prüfen, ob Binaries Service Fortschritte in der Bearbeitung der Queue zeigt
DDBTASK-2651 - Getting issue details... STATUS

In Dash anzeigen, ob relevante Systeme arbeiten

Prozessierung

Fehlerbeschreibung	Fehlercode/Log-Beispiel	Ursache	Behebung	weitere Infos für Entwickler	Optimierungsmöglichkeit
Im Report zu den Binaries sind 429-Fehler.	GeneralDataException: Couldnt get Data from url https://api.digitale-sammlungen.de/iiif/image/v2/bsb10598340_00007/full/full/0/default.jpg, status: 429, data: If you need your limits raised, please contact mdz@bsb-muenchen.de.	Limitierung durch Datenpartner	Freischaltung beim Datenpartner beantragen und Re-Ingest durchführen
Im Report zu den Binaries sind 404-Fehler. Die Binaries wurden mitgeliefert.	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. Entweder existiert die Datei nicht oder der Binaries Service ist prinzipiell nicht erreichbar oder aufgrund 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)
Dash-Prozess verharrt im Status "WAIT_FOR_BINARIES_SERVICE"		In dieser Stage werden die ALTOs gezogen. Das kann auch mal sehr lange dauern, da es sich oft um große Datenmengen handelt. Solange eine Queue im Binaries Service abgearbeitet wird, ist alles okay.	warten FIZ kann prüfen: Queue vorhanden? BS läuft?	Abfrage, ob Binaries fertig sind, ging auf falschen BS --> SparkApps waren korrekt auf dn01 konfiguriert, aber Dash-Backend auf dn09	Nutzern im Report den Status der Queue des BS anzeigen
Dash-Prozess verharrt im Status "PREPARE_LOCAL_BINARIES"		Der stage PREPARE_LOCAL_BINARIES ist ein Wartezustand, daher sind im Log keine Fehler sichtbar. Hier sollen Binaries auf den Local Binaries Provider hochgeladen werden. Der LBP ist aber nicht bereit bzw. verfügbar. Daher ist dieser neu zu starten.	FIZ: Local Binaries Provider neu starten
Transformation läuft in Fehler beim Abruf der refId eines Binaries	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	Binaries Service für Transformation nicht erreichbar	FIZ: Konfiguration der SparkApps prüfen BS läuft?	Obwohl es mittlerweile einen Binaries Service auf der dn09 gibt, der auch Queues annimmt, ist der auf dn01 weiterhin benötigt, obwohl eigentlich dn01 nicht mehr genutzt werden sollte. Dieser war zum Zeitpunkt der Transformation herunter gefahren bzw. auch nach Neustart überlastet und "eingefroren", da zusätzlich der der Knoten nn01 benötigt wird, der bereits wegen Änderung auf neues Cluster abgeschaltet war. DIO: Für die Ingest-Prozesse wird der Binaries Service benötigt. Aktuell ist dafür das alte Binaries Service Cluster vorkonfiguriert. Daher greifen alle Prozesse auf dieses Cluster zu. Wird der Knoten nn01 entfernt, läuft das Cluster nicht hoch und der Binaries Service ist nicht verfügbar. Somit scheitern alle Prozesse mit diversen Fehlern.	In Systemansichten sollte angezeigt werden, wenn konfigurierte Komponenten nicht verfügbar sind
Reports zu Export, Index, etc. nicht mehr vorhanden	UnknownHostExceptions beim Zugriff auf das Cluster und den AAS	s. DDBTASK-2481 - Getting issue details... STATUS : DNS-Server sporadisch nicht verfügbar. Somit Livy Server nicht erreichbar Es trat eine UnknownHostException auf. Damit sind für den Prozess benötigten Web-Services nicht verfügbar. Der gesamte Ingest-Prozess kann dadurch nicht durchlaufen und regulär ingestieren. Daher kommt es zum unvollständigem Report, bei dem Prozessschritte nicht angezeigt werden. Sobald die Hosts der Services über DNS wieder erreichbar sind, muss der Ingest nochmal durchgeführt werden.	FIZ: evtl. Neustart Dash-Backend	Netzwerker sind informiert.	Regelmäßiger Neustart der Komponenten Überwachung des DNS-Servers theoretisch müsste das Exception-Handling bei diesem Fehler den laufenden Prozess stoppen, zurücksetzen und später nochmal ausführen. Das kann man prinzipiell mehr oder weniger aufwendig implementieren. Da der Fehler aber normalerweise selten bis gar nicht auftritt, bzw. ein technisches Netzwerk-Problem darstellt, ist das bisher vermutlich aufgrund geringer Prio und den entstehenden Aufwand nicht implementiert worden
Bei Indexierung der referenzierten Institutionen werden Fehler angezeigt, obwohl der Report-Button grün ist und die zugehörigen GND-Links über die Suche auffindbar sind	SocketTimeoutException: Read timed out http://d-nb.info/gnd/6031336-5	Wahrscheinlich ist nur die Antwort der Abfrage verloren gegangen.	Der Fehler kann ignoriert werden. Bei erneuter Prozessierung sollte der Report wieder vollständig sein.
NullPointerException bei der Indexierung	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		DDBTASK-2648 - Getting issue details... STATUS
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.	Erneut prozessieren, wenn weniger Prozesse parallel laufen		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.		DDBDATA-8757 - Getting issue details... STATUS

Portale

Fehlerbeschreibung	Fehlercode/Log-Beispiel	Ursache	Behebung	weitere Infos für Entwickler
METS/MODS: Bild wird weder n der Vorschauansicht noch auf der Bildbühne angezeigt. Öffnet man den METS-Viewer ist es allerdings vorhanden. Das Bild konnte vom BinariesService scheinbar nicht korrekt geladen werden (Breite und Höhe betragen 0.		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
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	Interner Serverfehler - 500		Neustart Q1 Frontend	DDBTASK-2641 - Getting issue details... STATUS
Logos der Institutionen werden nicht aktualisiert		Fehlender Parameter bei einem der beiden Binaries-Aufrufe im Mapping	Mapping korrigieren	DDBTASK-2637 - Getting issue details... STATUS
Logo einer Institution erscheint schwarz bzw. mit schwarzem Hintergrund		Transparenz in der Bilddatei	Logo als Jpeg hochladen	DDBTASK-2336 - Getting issue details... STATUS Zur Erklärung: PNGs enthalten pro Pixel 4 Kanäle: RGBA, also Rot, Grün, Blau und Alpha (Transparenz). Unser internes Format (Tif mit Jpeg-Kodierung) unterstützt aber keine Transparenz. Jetzt gibt es zwei Möglichkeiten mit einem Bild mit Transparenzinformationen umzugehen: man rendert das Bild auf einen Hintergrund, da muss man für eine Hintergrundfarbe entscheiden, meistens weiß. man lässt die Transparenzinformationen einfach weg, dann kommt der echte Hintergrund des Bildes wieder zum Vorschein. Damit erlaubt man dem Ersteller des Bildes den Hintergrund für Umgebungen die keine Transparenz unterstützen selbst zu wählen. Wir haben uns für Variante 2 entschieden, also die Transparenzinformationen wegzulassen. Für das vorliegende Logo heißt das aber leider dass das ganz Bild schwarz ist, denn in dem Bild sind alle Pixel schwarz und welche zu sehen sein sollen ist nur durch die Transparenz geregelt.

Page tree

Fehlermeldungen