...
| Info |
|---|
| Auf dieser Seite werden Fehler, 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.
Bitte gerne ergänzen!
| Fehler | Fehlercode/Log-Beispiel | Ursache | Behebung | weitere Infos für Entwickler | Optimierungsmöglichkeit | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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. | ||||||||||||||
| 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: |
| 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: | ||||||||||||||||
Ingest-Button reagiert nicht | FIZ: Neustart Dash Frontend + Backend + Binaries Service | Regelmäßiger Neustart der Komponenten | ||||||||||||||||
Reports zu Export, Index, etc. nicht mehr vorhanden | UnknownHostExceptions beim Zugriff auf das Cluster und den AAS | s. | FIZ: | Netzwerker sind informiert. |
| |||||||||||||
| 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: |
| In Systemansichten sollte angezeigt werden, wenn konfigurierte Komponenten nicht verfügbar sind | |||||||||||||
| 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 | ||||||||||||||||
| 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:
| |||||||||||||||
| 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: | ||||||||||||||||
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 |