Doppelte Units behandeln

[paflov]

Durch einen Bug im Testcenter kann in den Antwortdaten kann ein- und die selbe Unit mehrfach vorkommen, wenn alles sehr schnell ging. Die zweite (oder sogar dritte, vierte...) Instanz der Unit kann keine Responses enthalten und nur einen einzigen Unit-State (vermutlich immer {"PLAYER":"LOADING"} oder {"PLAYER":"RUNNING"}). Soweit ich das übersehen kann, müsste das erste vorkommen der Unit immer das Korrekte sein.

Beispieldaten: siehe unit-8 und unit-12

Bis das Problem im Testcenter gelöst ist, sollte die itc-toolbox mit diesem Fall umgehen können.

[mechtelm]

Hm Daten legen nahe, dass dem nicht so ist: Es gibt geänderte Daten in den Dopplungen. Die ict-ToolBox müsste also den Timestamp auswerten?

doppelte.xlsx

[paflov]

Wir beobachten verschiedene Fehlverhalten.

1 a) Phänomen: Bestimmte name_suffices scheinen zu fehlen.

Befund: Sie fehlen nicht, sie tauchten nur in der Ergebnisliste nicht auf, weil sie keine Tests hatten.

Erklärung: Etliche Teilnehmer haben sich angemeldet, aber keinen Test gestartet.

b) Phänomen: ein name_suffix (15) kommt zweimal vor, person_id und login_id sind gleich

Befund:

• die person hat zwei mal den selben test:
• 1. [testId:2864]: vermutl. beim laden abgebrochen (laststate ist leer), 12:40 gestartet - kein state, keine logs
• 2. [testId:2863]: normal durchgeführt, 13:33 letzter state, logs (10:48-11:33 server, 8:18-9:03 client), hatte zunächst einen Error beim starten

Besonderheiten:

1. Die Computeruhr des Teilnehmers ging um 1,5h falsch.
2. Bug: timestamp_server scheint in den logs ggü. tests immer zwei Stunden verschoben, obwohl beides server-tiemstamps sind. #127

Erklärung: ?

c) Phänomen: Phänomen: ein name_suffix (1) kommt zweimal vor, person_id und login_id sind verschieden

Befund:

• 1. [testId:2859][personId:2767][loginId:2356] normal durchgeführt, 13:09 letzter state, logs (10:42 - 11:09 server, 10:42 - 11:09 client), hatte zunächst einen error beim starten
• 2. [testId:2848][personId:2768][loginId:2357] normal durchgeführt, 13:40 letzter state, logs (10:38 - 11:40 server, 10:38 - 11:40 client)

Erklärung: ?

2 Durch mangelndes Buffering werden zwei tests gleichzeitig angelegt siehe #48

[paflov]

Durch aufwendige Tests mit simuliertem, instabilen Netzwerk konnten beide Fälle 1b und 1c nachgestellt werden.

Folgende Fehlersituationen sind aufgetaucht:

A) Der erste Aufruf eines Logins und der zweite waren (fast) gleichzeitig. Dies führte dazu, dass SessionDAO::getOrCreateLoginSession zweimal zu createLoginSession verzweigt und die login_session doppelt auftaucht.

B) Wenn wenn SessionDAO::countPersonSessionsOfLogin (dient zur Ermittlung der Ordnungzahl in _namesuffix) zweimal gleichzeitig ausgeführt wird, dann kommt auch das selbe Suffix heraus.

Lösung a) Workaround Beide Probleme betreffen nur die Bezeichner in den Ergebnistabellen und im Gruppen-Monitor. Würde man als _namesuffix von mit _run_hotrestart generierten _personsessions zufällig generierte Codes oder z. B. einen code, der die _person_sessionid enthält wählen, wären sie auch unterscheidbar und das Problem somit gelöst.

b) finale Lösung Denn würde der Fall A zu einer veränderten Datenstruktur führen: Zwei verschiedene _loginsessions wo es nur eine geben sollte. Das hat zwar sonst keine (bekannten) Konsequenzen, aber stellt eine Gefahrenquelle in der Zukunft dar. Die Queries in createLoginSession und getLoginSession müssten eigentlich zusammengefasst werden. Analog wohl auch getPersonSession und createPersonSession.