Allgemeine Fehlerklassen und Umgang
Bei der Archivierung von Nachrichten gibt aktuell grundsätzlich zwei verschiedene Arten im Umgang mit fehlerhaften Nachrichten:
- Shutdown: Der betroffene Container wird heruntergefahren. Fehler finden sich in den Logs des Containers.
- Service-Neustart: Der betroffene Container wird neugestartet. Tritt ein Fehler während der Verarbeitung einer Message auf, wird diese zurück in die RabbitMq gegeben.
- Logging: Fehler werden geloggt und ansonsten ignoriert.
- Eintrag Error-Queue: Der betroffene Service gibt den Fehler in die Error-Queue. Dieser wird später mit dem entsprechenden Stacktrace in der Datenbank gespeichert.
Je nach Service und Typ wird unterschiedlich mit den Fehlern umgegangen.
| Fehlerklasse | Starter-Service | Data-Loader | Archive-Writer | Archive-Index-Writer | Finish-Service |
|---|---|---|---|---|---|
| Falsche/fehlende Konfiguration 1 | Shutdown | Service-Neustart | Service-Neustart | Service-Neustart | Service-Neustart |
| Umsystem nicht erreichbar 2 | Shutdown | Service-Neustart und Message bleibt in der Queue | Service-Neustart und Message bleibt in der Queue | Service-Neustart und Message bleibt in der Queue | Service-Neustart und Message bleibt in der Queue |
| Technisch fehlerhafte Nachricht | - | Logging | Logging | Logging | Logging |
| Restliche Fehler | Shutdown | Service-Neustart und Message bleibt in Queue | Eintrag in die Error-Queue | Eintrag in die Error-Queue | Logging |
FAQs
Wie wirken sich Fehler in der ErrorQueue auf Umsysteme und -Prozesse aus? Wie wird mit ARCHIVING_FAILED (ARF) in der B2B umgegangen?
Nachrichten, die in die ErrorQueue ausgesteuert werden, wurden nicht erfolgreich archiviert und bekommen den Status ARF in der B2B. Das Clearing von solchen Nachrichten in der B2B erfolgt dadurch, dass der (in der B2B) geloggte Fehler zunächst analysiert wird. Sollen die Nachrichten nochmal in die Archivierung gegeben werden, so können diese über die B2B Statusänderung den Status “manuell beendet” (MAN) erhalten. Diese werden dann (getriggert durch einen erneuten Start des statischen Starter-Services für deren Zeitraum) von den Data-Loadern erneut in die Archivierung gegeben.
Kann eine Message aus der ErrorQueue vom Finish-Service nicht richtig verarbeitet werden, so wird der Fehler nur geloggt und die Nachricht in der B2B verbleibt im Status “In Archivierung” (ARP). Das Clearing einer solchen Nachricht erfolgt dann über die Auswertung der Finish-Service Logs, welche eindeutig zur Nachricht zugeordnet werden können.
Wie stellen wir sicher, dass wiederholtes Zurückspielen der Nachricht in die Ausgangsqueue nicht zu Endloschleifen/Performanceproblemen führt?
Durch ein Monitoring und Alarming der Queues und Services. Circuit Breaker (Hystic?) sind in unserem (relativ einfachen) Fall (alle Services auf einem Knoten) aktuell nicht notwendig und wären sehr komplex.
View Me Edit Me