Manchmal verweigerte der PB-Server (unter Linux) das Laden eines Spielstandes mit der Fehlermeldung à la „Korrupte Datei“. Durch das Ändern der Schildertexte konnte ich aber dafür sorgen, dass ein Spielstand wieder ladbar wird.
Das fällt jetzt endlich weg, denn wahrscheinlich habe ich eine bessere Lösung gefunden.
Man muss die DLL msvcp71.dll in den Civ-Verzeichnissen löschen, damit die Wine-Variante dieser DLL genutzt wird.
Mir kam grad der Gedanke, dass es praktisch waere beim score im pbspy log auch die Differenz anzuzeigen. Da muss man z.B. nicht alle differenzen selber ausrechnen um Wunderkandidaten zu bestimmen.
Umsetzung ist ja trivial, nur nicht so trivial fuer vergangene Eintraege (nicht so schlimm, da machen wir einfach decreased -> -1, increased -> +1).
Achtung Spoiler:
Ja, das wäre eine angenehme Verbesserung.
Bin gerade über eine Pythondatei gestolpert, die ich bisher übersehen hatte: Civ4/Assets/Python/EntryPoints/PbMain.py.
Nach diesem Satz seid ihr aber so enttäuscht wie ich nachdem ich sie studiert hatte: Inhalt ist uninteressant
Mir ist grad noch was etwas wichtigeres aufgefallen. Das trim des statusCache im php web funktioniert nicht...
Da gibt es diese Abfrage
Ich versteh grad nicht was das genau bezweckt bzw. wo das Problem ist trim_database_tables auf alle IDs auszufuehren...Code://Trim big caches and log //FIXME: This method is not reliable. Trim could only be operate on a // subset of all game ids. if( isset($ret["id"]) && $ret["id"] % 101 == 0 ){ trim_database_tables($gameId); }
Muss mal aufraeumen Tabelle ist schon etwas groesser geworden mit der Zeit
Achtung Spoiler:
Das könnte ein Unterschied zwischen MySQL und SQLite sein.
Was hat es denn mit dem % 101 auf sich?
Achtung Spoiler:
Die Zahl ist beliebig und steuert nur wie oft der Trimbefehl getriggert werden soll. In diesem Fall in jedem 101 Durchlauf. Es ging letztlich nur darum, dass es nicht bei jeder Aktualisierung ausgeführt wird.
Achja, das ist ja die ID vom Eintrag, nicht vom Spiel. Muss ich dann mal schauen warum das mit MySQL nicht funktioniert...
Achtung Spoiler:
MySQL ist echt daemlich.
http://stackoverflow.com/a/14302701/620382
Das geht nicht ohne weiteres mehr, weil da irgendein transaction timeout kommt. Manuell mit ids dauert das gerade ne halbe Stunde pro game die 1,5 mio eintraege zu loeschen
Achtung Spoiler:
Boar MySQL ist echt mal schlecht. Werd in Zukunft wohl postgres aufsetzten. Wird ja unter Oracle auch nich besser werden...
http://stackoverflow.com/questions/3...-file-in-mysql
http://bugs.mysql.com/bug.php?id=1341
Edit: Aber der "fix" fuer das truncate ist bei mir im git...
Achtung Spoiler:
Habe den Fix übernommen.
Hast du die neue Variante für die Punktenachricht im Log intern schon erstellt oder ist das noch offen?
Zu dem Fehler mit dem Cache: Ist schon erstaunlich was ein kleiner Fehler alles bewirken kann 1,5 Mio Einträge werden ja auch einigen Platz beansprucht haben, da jeweils der letzte json-String vom Server gespeichert wurde (wenn ichs richtig in Erinnerung habe).
Wahrscheinlich gibt es in den Datenbanksystemen spezielle Funktionen für Caches/flüchtige Dateien. Bei der Thematik kenne ich mich leider nicht aus.
Ich hoffe mal das tut in SQLite auch...Zitat von Ramkhamhaeng
Habe den Fix übernommen.
Ist noch offen, nicht so viel zeit zum coden Momentan :/Hast du die neue Variante für die Punktenachricht im Log intern schon erstellt oder ist das noch offen?
Aber die Umsetzung ist eigentlich trivial. Nur die Frage wie wir Legacy-Records behandeln
Variante 1: Zusaetzliches Attribut.
+ Sehr einfach umzusetzen
+ Einfache migration
- Redundante Datenhaltung
Variante 2: Attribut ersetzen
- Schwierige migration (geht sicher auch irgendwie)
+ Keine Redundanten Daten
= Man koennte alte increase/decrease ueber spezielle Magic-Werte abbilden
Variante 3: Zusaetzlicher Record
- Filtern macht keinen Spass
Ja das waren >50 GB. Und die krieg ich jetzt nicht so einfach weg wegen diesem kaputten innodb designfehler (12 Jahre alter bug)Zu dem Fehler mit dem Cache: Ist schon erstaunlich was ein kleiner Fehler alles bewirken kann 1,5 Mio Einträge werden ja auch einigen Platz beansprucht haben, da jeweils der letzte json-String vom Server gespeichert wurde (wenn ichs richtig in Erinnerung habe).
Wahrscheinlich gibt es in den Datenbanksystemen spezielle Funktionen für Caches/flüchtige Dateien. Bei der Thematik kenne ich mich leider nicht aus... naja erstmal /var/lib/mysql ausm backup raus und normal vor jedem backup ein mysqldump ...
Achtung Spoiler:
Hm, 50 GB :-( Das ist ja dann auch als Netzwerktraffic aufgelaufen. Ist mir schon peinlich, so einen Designfehler gemacht zu haben. Derzeit wird alle 10 Sekunden eine Nachricht mit allen Statusinformationen versendet.
Um das Problem an der Wurzel zu packen, werde ich die Senden-Routine überarbeiten und nur eine 'Alive'-Nachricht senden, wenn sich an den Spielerdaten auf dem Server nichts geändert hat.
Also schlimm ist das nicht, das ist ja nur interner Traffic zwischen 2 VMs. Und selbst wenn 50 GB, so what - nur im Backup tuts halt weh. Aber an sich ist das mit dem Differenziellen (oder on demand) update ne gute Sache.
Achtung Spoiler:
So die pbspy-deltas funktionieren jetzt :-). Ich habs sogar hinbekommen alle bisherigen eintraege zu konvertieren. Das ist echt sehr praktisch und einfach mit data migrations in django. Habs mit 3 Schritten, delta hinzufuegen, delta historisch auffuellen, increase entfernen.
Interessanterweise haben wir zwei kaputte Score Logeintraege, die scheinen im Rahmen eines AdminSave doppelt eingetragen worden zu sein, da ist die delta Berechnung dann natuerlich inkonsistent. Ich vermute eine racecondition innerhalb des set_from_dict. Interessanterweise werden diese Eintraege garnicht im webinterface angezeigt... Ich habe echt keine Ahnung warum.
Feb. 2, 2015, 7:07 p.m. 42 - Game saved by Ramkhamhaeng AdminSave. Zu dem Zeitpunkt gibt es doppelte score changes from ANNO und borgg in der Datenbank...
Achtung Spoiler:
Berechtigungen
Zitieren