ConcurrentModificationException in the GameRoomManager

[SKoschnicke]

Ein Team ist beim Trainieren ihres Clients auf einen Fehler im Server gestossen. Der Server beendet sich mit folgender Fehlermeldung:

18:13:54 ERROR sc.networking.clients.XStreamClient - Unknown Communication Error
java.util.ConcurrentModificationException: null
        at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
        at java.util.HashMap$ValueIterator.next(HashMap.java:1471)
        at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1042)
        at sc.server.gaming.GameRoomManager.joinOrCreateGame(GameRoomManager.java:156)
        at sc.server.Lobby.onRequest(Lobby.kt:65)
        at sc.server.network.Client.notifyOnPacket(Client.java:93)
        at sc.server.network.Client.onObject(Client.java:230)
        at sc.networking.clients.XStreamClient.receiveThread(XStreamClient.java:115)
        at sc.networking.clients.XStreamClient$1.run(XStreamClient.java:77)
        at java.lang.Thread.run(Thread.java:748)

[xeruf]

Das Problem erscheint mir, dass zwar alle einzelnen Methoden im GameRoomManager synchronized sind, aber es können immer noch zwei verschiedene Methoden gleichzeitig den state verändern.
Ich würde fast sagen, dass der GameRoomManager auf seinem eigenen Thread operieren sollte, sodass immer nur eine Sache gleichzeitig passiert.

[SKoschnicke]

Benutzt der Server denn ueberhaupt mehrere Threads?

[xeruf]

Naja, wahrscheinlich um mit mehreren Clients gleichzeitig kommunizieren zu können. Damit der obige Fehler passiert, muss irgendwo ein Thread die rooms verändert haben während der Iterator aktiv war.

[SKoschnicke]

Ja, klingt plausibel. Dann also den GameRoomManager in einem eigenen Thread und die anderen Threads kommunizieren per message passing damit? Klingt nach einer groesseren Aenderung...

[xeruf]

Jup, hab ich so gedacht. Ja, das ist ne größere Änderung, aber ich weiß nicht wie man es sonst wirklich sicher machen kann.

[xeruf]

Vielleicht können wir da auch ein Kotlin pattern verwenden: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/actor.html
Bzw hier eine bessere Introduction: https://medium.com/@jagsaund/kotlin-concurrency-with-actors-34bd12531182
Ein Actor ist so ziemlich das wovon wir bisher geredet haben. Er empfängt Nachrichten und sendet welche aus. Und die return value von so ziemlich jeder an die Clients gerichteten Methode ist ja eine Message.

[SKoschnicke]

Ich bin mir nicht sicher, aber ich glaube, dass der GameRoomManager gar nicht direkt mit den Clients kommuniziert. Aber den koennten wir als Actor modellieren, ja.

[xeruf]

Naja indirekt über die Lobby halt. Aber die leitet auch nur die Nachrichten hin und die Antworten zurück ^^

[SKoschnicke]

Und die Lobby existiert doch auch nur einmal im Server.

[xeruf]

Und die Lobby existiert doch auch nur einmal im Server.

Was soll uns das sagen?

Ich frage mich auch gerade, wie viel Sinn es überhaupt macht den GameManager und ClientManager von der Lobby zu separieren, weil die ja trotzdem ziemlich eng gecoupled sind.

[SKoschnicke]

Und die Lobby existiert doch auch nur einmal im Server.

Was soll uns das sagen?

Ich dachte, wenn die Lobby nur einmal existiert, koennen da ja nicht mehrere Aufrufe parallel durch. Aber es geht darum, dass von mehreren Threads durchaus parallel auf die eine Lobby zugegriffen werden kann. Verstehe.

Die hohe Separierung ist eine Altlast. In den meisten Faellen kann man da was zusammenlegen.