Feature/game state recovery restart#109
Conversation
…tate-recovery-restart
…tate-recovery-restart
…ervice usage in lobby controller test
the-only-queen-anna
left a comment
the-only-queen-anna
left a comment
There was a problem hiding this comment.
Also, ich habe mir das ganze durchgesehen, auch kurz mit AI darüber diskutiert, und habe folgende Bedenken:
- Bei jeder Aktion (Lobby erstellen, joinen, verlassen, Spiel starten, Hinweis geben, Karte aufdecken, ...) den ganzen Game State zu aktualisieren und als File neu zu speichern, ist extrem IO-aufwendig. Durch das ATOMIC_MOVE werden zwar wenigstens Konsistenz-Probleme vermieden, aber wir werden andere Probleme haben, weil wenn ich das richtig sehe, die Funktion keinen neuen Thread startet und daher bei den ganzen Requests blockierend wirkt. Das heißt, jede Request muss warten, bis der ganze Game State gespeichert worden ist, bevor sie verarbeitet wird.
- Eine JSON-File bringt uns auch nur was bei einem graceful shutdown oder wenn wirklich Spring Boot crasht, sobald der Container was abbekommt ist die File dann auch weg, schützt also nur mäßig.
- Warum nicht einfach eine simple Datenbank? Wäre vermutlich mit weniger Custom Code, der doch irgendwo auch fehleranfälliger ist, erledigt. Da müssten wir nur uns nur ein Datenbankschema überlegen.
- Eine Alternative für das ständige Updaten der Files wäre ein Thread, falls wir keine Datenbank wollen, der z.B. alle 30 Sekunden einen Snapshot macht und den dann in einem File speichert. Dann ersparen wir uns die Synchronisationsprobleme etc.
- Ich finde die Variante, wie die Lobbies wieder erstellt werden, etwas ineffizient. Jede Lobby einzeln neu erstellen, alle Spieler joinen, bei jedem Spieler doppelt den username auf null checken, und dann einzeln in die Liste schreiben dauert ewig, falls es keine RAM-Probleme macht hätte ich einfach die ganze Liste genommen, kopiert und dann als Ganzes wieder ausgetauscht, um bisschen Zeit zu sparen.
Also sollten wir als erstes prüfen, ob die Recovery-Variante zur Art von Ausfall passt, vor der wir uns schützen wollen, und dann nochmal überdenken, wie oft und was gesavet werden muss. Z.B. würde ich nur ingame-lobbies saven, die, die noch kein Spiel gestartet haben, können uns theoretisch auch egal sein (joinen und Rolle auswählen ist eine Sache von nicht mal 10 Sekunden).
Mir wurde kommuniziert, dass eine Datenbank erst später geplant ist bzw. nicht mehr sinnvoll in diesen Sprint passt. Deshalb habe ich versucht, mit möglichst wenig zusätzlicher Infrastruktur zumindest Backend-Restarts besser abzufangen. Die Lösung ist also eher Recovery-Infrastruktur für den jetzigen Sprint, nicht als Ersatz für eine spätere Datenbank gedacht.
Danke fürs Feedback, die Punkte versteh ich. Die JSON-Lösung war hier eher als temporäre Recovery-Lösung gedacht, weil eine DB-Lösung soweit ich verstanden hab eher später geplant war und ich für den Sprint noch eine Möglichkeit einbauen wollte, Backend-Restarts abzufangen. Ich seh aber die Nachteile auch voll vor allem I/O bei jeder Änderung und dass JSON natürlich keine langfristige Persistenz ersetzt. Für später wären asynchrone Snapshots oder eine DB viel sinnvoller. Ich hab die Persistenz zusätzlich manuell getestet: Nach Lobby-Erstellung wird tatsächlich state.json erzeugt und gespeichert, Recovery lädt den Zustand beim Neustart wieder ein. Soll ich state.json bzw. den data Ordner committen ?? |
|
Nein, ich würde die Datei nicht committen, solange wir wissen, dass sie erstellt wird, sobald es states gibt, die persistiert werden müssen. Mein Vorschlag wäre, die Back-up Strukur so wie sie in deinem Code ist, zu übernehmen, aber halt nicht bei jeder Aktion zu updaten sondern alle 30-60 Sekunden, um I/O Aktivität zu sparen (ich weiß, bei uns ist es ja nur hypothetisch, aber dann würde es wesentlich besser skalieren, als bei jeder Aktion). Und ich gehe davon aus, dass wenn der Server zu tun kriegt, es immer viel auf einmal ist, deshalb auch bei wenigen aktiven Spielen gleichzeitig evtl. Verzögerungen auftreten können. Was hältst du von dieser Zwischenlösung? |
the-only-queen-anna
left a comment
the-only-queen-anna
left a comment
There was a problem hiding this comment.
LGTM; danke für die Anpassungen. Das ist eine saubere Übergangslösung, bis wir in Sprint 3 die Datenbank haben.
| org.junit.jupiter.api.Assertions.assertEquals( | ||
| SystemSnapshot.CURRENT_SCHEMA_VERSION, snapshot.schemaVersion()); | ||
| org.junit.jupiter.api.Assertions.assertEquals(lobbySnapshots, snapshot.lobbies()); | ||
| org.junit.jupiter.api.Assertions.assertEquals(gameSnapshots, snapshot.games()); |
There was a problem hiding this comment.
Können wir bitte normale imports machen und asserEquals normal verwenden 🥹
XtophB
left a comment
XtophB
left a comment
There was a problem hiding this comment.
LGTM, Habe Kommentar in einer Testklasse hinterlassen, können wir in dieser PR fixen oder im Post sprint refactoring. Dir überlassen.
|
3 participants
Context
Implements persistent backend state storage to preserve active lobbies and games across backend restarts by automatically saving runtime snapshots after state changes.
Description
Added persistence infrastructure that stores the current in-memory system state whenever lobby or gameplay changes occur. Runtime snapshots now include active lobbies, player assignments, and ongoing game sessions, enabling recovery services to restore consistent state after restart.
Changes in the codebase
SystemStatePersistenceServiceto collect and persist current lobby and game snapshotsgetLobbySnapshots()inLobbyServicefor serializable lobby state retrievalgetGameSnapshots()inGameServicefor serializable game state retrievalGameRecoveryStateGameStateDataTransferObjectdirectlyAdditional information
This implementation improves reliability by: