Server disqualifiziert Clients wegen Soft-Timeout obwohl Zug rechtzeitig gesendet wird

[SKoschnicke]

Wir hatten ja schon immer das Problem, dass es vorkommen kann, dass der Server durch den Garbage Collector in dem Moment angehalten wird, wo ein Client einen Zug sendet, und dass es auch schon sehr nah an dem Soft Timeout (2s) dran ist. Wenn der Server dann erst nach den 2s wieder weiterlaufen kann, weil der GC Lauf einige hundert ms gedauert hat (was durchaus vorkommen kann), wird der Client disqualifiziert, obwohl er den Zug rechtzeitig sendet.

Das haben wir diese Saison recht gut im Griff, durch optimierung der Startparameter des Servers (habe ich hier gestern auch nochmal dokumentiert: https://cau-kiel-tech-inf.github.io/socha-enduser-docs/#soft-timeouts).

Leider tritt dieses Problem bei langen Testlaeufen der Schueler wohl noch auf, auch wenn sie die Parameter verwenden. Das ist nicht verwunderlich, weil das ein anderes Szenario ist, als das unseres Wettkampfservers.

Nun gibt es aber noch eine Moeglichkeit, das in den Griff zu bekommen. Mit System.gc() kann man dem GC den Hinweis geben, dass jetzt ein guter Zeitpunkt waere, einen GC Lauf zu machen. Wenn man das direkt nach der Zuganforderung im Server einbaut, koennte das Problem verschwinden. Das eigentlich aufwaendige dabei ist, zu testen ob das wirklich funktioniert. Du muesstest also erstmal das Problem messbar nachstellen, dann System.gc() einbauen und nochmal messen.

Aber du brauchst einen client der die genaue zeit misst, die er braucht und am besten auch nahe am soft timeout operiert. Diese zeiten vergleichst du dann mit den zeiten, die der server misst. Bei grossen unterschieden (>100ms) hast du das GC problem.

Dann kannst du noch die GC Lauefe loggen, das geht ueber parameter die ich in dem oben verlinkten artikel auch mit drin habe.

Dann baust du das System.gc() ein und guckst, ob das Problem nicht mehr auftritt. Dabei immer im rahmen von automatisierten testdurchlaeufen mit dem non-gui-server testen. Brauchst also noch ein kleines script, was den client immer zweimal startet. Und wenn die clients sich beenden direkt nochmal fuer das naechste testspiel, das ein paar hundert mal.

[soerendomroes]

Mir scheint, dass die Timeoutabfrage bei einem Spielerwechsel zweimal ausgeführt wird. Sollte man mal im Auge behalten. Die Clients selbst senden nur einmal.

[xeruf]

Eine alternative Option wäre, am Ende/Anfang eines Spiels System.gc() aufzurufen. Da sollte ja nichts zeitkritisches sein, und es liegen am ehesten Garbage-Objekt von letztem game herum, die nicht mehr gebraucht werden.

[SKoschnicke]

Wir brauchen eine gute Möglichkeit, das automatisiert zu testen. Leider tritt das Problem nicht so zuverlässig auf, als dass man dir einen Lauf feststellen könnte, dass es behoben wurde. Daher mein oben beschriebenes Vorgehen. Könnte man vielleicht mit Gradle automatisch testen?

[xeruf]

Gradle führt alle tests bisher korrekt aus, die kann man natürlich auch noch ausweiten.

[SKoschnicke]

Ein einfacher Unit-Test ist dafuer nicht ausreichend. Man muss ja die Clients mehrmals unabhaengig vom Server starten (wenn man die Clients wie in den Unit-Tests simuliert, wuerde das mit dem GC interferieren und keine zuverlaessigen Ergebnisse liefern).

[xeruf]

Okay, dann kann man eine eigene Gradle task dafür schreiben. Ich kümmer mich dann mal drum.

[SKoschnicke]

#177 wäre wichtiger

[xeruf]

Ich weiß, ich hab das im Blick. Aber #177 sollte nicht sonderlich kompliziert sein.

[xeruf]

Müsste man hierfür nicht eigentlich einen eigenen Client schreiben, der speziell dafür ausgelegt ist? Aber auch abgesehen davon, wird so ein Test natürlich sehr zeitintensiv werden. Wenn wir die ganze Zeit am Limit operieren muss man das ja schon ne Stunde oder so laufen lassen um ordentliche Ergebnisse zu bekommen...

[SKoschnicke]

Ja, hier brauchen wir einen Client, der mit dem Senden seines Zuges bis kurz vor das Zeitlimit wartet. Und ja, das ist ein Zeitintensiver Test, da ein Spiel dann 2 (Spieler) * 30 (Runden) * 2 (Sekunden Zugzeit) = 2 Minuten Zeit benoetigt. Dieser Test sollte also nur optional laufen.