Bug #18

Geokrety-Inkonsistenz

Added by following over 7 years ago. Updated over 4 years ago.

Status:in Arbeit 20%% Done:

20%

Priority name:3 hoch
Assignee:-
Target version:-
Ticket Referenz:4479 following 7/2012 Kategorien:geokret

Description

In OCE5C1 wird das Geokret "A sio!" angezeigt, das aber laut Geokrety-History und Daten auf geokrety.org nicht in dem Cache ist. Bug in util2/cron/modules/geokrety.class.php, oder kann sowas durch fehlerhafte Importdaten entstehen? Beides sollte nicht sein. Evtl. geben die Datenbankinhalte Aufschluss, was schiefgelaufen ist.

gk-inkonsistenz.txt Magnifier - Inkonsistenzen zwischen gk_item_waypoint und gk_move_waypoint (226 KB) following, 06/12/2013 02:33


Related issues

Blocks OC Entwicklung - Feature #264: Verloren gegangene Geokrets markieren offen

Associated revisions

Revision 8ea1c08f
Added by bohrsty about 7 years ago

fixed handling of geokrety waypoints, corrected indents, updates #18

Revision d3b188d4
Added by following about 7 years ago

fixed geokrety waypoint import; update #18

Revision c5d43967
Added by following about 5 years ago

added geokrety xml file archive option; updates #18

Revision 7d755912
Added by following almost 5 years ago

add geokrety diagnosis tool; updates #18

History

#1 Updated by following over 7 years ago

Aus RT-Ticket 2930:

"Sometimes, i need to resync the entire records, because some geokreties are in wrong
geocache for any reason. But then i get timeout errors when reqeuesting all records (with
modifiedsince=200500000....) ... sometimes ...."

Kommentar dazu vom Geokrety-Entwickler: http://teamwiki.opencaching.de/index.php/Tickets:2930_-_Fwd:_Geokrety_integration

#2 Updated by following over 7 years ago

  • Kategorien set to geokret

#3 Updated by following about 7 years ago

Ob hier immer noch Inkonsistenzen entstehen? Das RT-Ticket 2930 ist schon zwei Jahre alt.

Irgendwer müsste sich mal mit dem Thema "kompletter Resync" beschäftigen und einen Neuimport der Geokrety-Daten machen; danach kann man weiterschauen.

#4 Updated by bohrsty about 7 years ago

sollte man das nicht mal auf die gekrety-api um stellen? damit muesste man die eigene datenhaltung von krets umgehen koennen... ich lese mich mal ein, gibt es irgendwo eine "zusammenfassung" was oc mit krets machen kann?

#5 Updated by following about 7 years ago

Opencaching.pl nutzt die API - und kam ins Schleudern, als die neulich für ein paar Tage ausfiel. Also viewcache.php direkt an die Geokrety-API zu hängen fände ich zu gefährlich - mit replizierten Daten sind wir unabhängiger. Kann natürlich sein, dass sich das über die API besser lösen lässt - aber vielleicht gibt es hier auch gar kein Problem mehr?

Eine Doku für OC.de ist mir nicht bekannt. Die Geokrets werden im Listing angezeigt, in Kartenpopups (nur die Anzahl), und sie werden als Travelbug in GPX ausgegeben.

#6 Updated by bohrsty about 7 years ago

ok, aber man kann wird doch api-zugriffe so steuern und mit sinnvollen fehlermeldungen versehen koennen, dass bei nichterreichen nichts passiert, ausser das man die funktion nicht nutzen kann, also die anzeige an den diversen stellen nicht zu sehen ist...

ausserdem, falls man auf weitere funktionen wie krety loggen von der oc-seite aus spekuliert etc. macht man sich doch eh von der api "abhaengig"... (aber ich bin kein erfahrener entwickler und wuerde da auf dein urteil vertrauen...)

#7 Updated by following about 7 years ago

bohrsty schrieb:

ok, aber man kann wird doch api-zugriffe so steuern und mit sinnvollen fehlermeldungen versehen koennen, dass bei nichterreichen nichts passiert, ausser das man die funktion nicht nutzen kann, also die anzeige an den diversen stellen nicht zu sehen ist...

Wenn's bei Nichterreichen nicht klemmt - ja. Wenn man auf http://www.opencaching.de zugreifen will, während die Seite down ist, ist Geduld angesagt.

Im Listing könnte es sich per JavaScript/Ajax lösen lassen - erst das Listing anzeigen und dann die Geokret-Daten "im Hintergrund" nachladen und einblenden. Beim Karten-Popup wird das haarig, weil man eigentlich vorher wissen muss wir groß das Fenster wird - ansonsten muss in den generierten DOM-Objekten von Google Maps rumgepfuscht werden.

Oder weißt du noch ne andere Lösung?

#8 Updated by bohrsty about 7 years ago

achso meinst du das... ich hatte eher daran gedacht, erst die erreichbarkeit abfragen (fsockopen() mit timeout etc.) und wenn das fehlschlaegt, die gesamten anzeigen umgehen oder mit entsprechenden "fehlermeldungen" darauf hin zu weisen...

#9 Updated by following about 7 years ago

Mir ist generell unwohl bei dem Gedanken, die Seitenberechnungszeiten von OC.de von der Performance des Geokrety-Servers abhängig zu machen. Im Moment haben wir <= 100 ms bei viewcache.php, das ist perfekt.

Ein anderes Problem ist, dass wir die Systemlast des Geokret-Servers in die Höhe treiben würden: Jeder viewcache-Aufruf, inkl. derer von Suchmaschinen, würde eine API-Abfrage auslösen - heute waren es z.B. 50.000 viewcache-Abrufe. Das dürfte ein Vielfaches von dem sein, was Geokrety bislang an Abrufen hat.

Und ich hatte oben die OKAPI vergessen: Damit kann man die Krets auch abfragen, und die Daten kommen aus den gleichen Tabellen (auch bei OC.pl). Die OKAPI müsste dann auch umgebaut werden auf Geokret-API-Nutzung.

Alles in allem sehe ich da zu viele Probleme und würde lieber bei den replizierten Daten bleiben.

#10 Updated by bohrsty about 7 years ago

ok, dann bin ich bei dir... zusammengefasst: alle anzeigenden aktionen auf cache- und kartenseiten per replikat, alle aktionen, die eine authentifizierung erfordern (via api-key) und evtl. die anzeige im profil (krets in meinem besitz) muessen per api laufen...

da sich mit einfuehrung der api die maximalen synchronisierungsintervalle auf 10 tage verkuerzt sind, werde ich mich die naechsten tage mal durch den code lesen und schauen, ob die synchronisierung noch so implementiert ist, wie es vom krety-team vorgesehen ist und ob wir beim verarbeiten evtl. inkonsistenzen erzeugen koennen...

#11 Updated by following about 7 years ago

  • Assignee set to bohrsty

#12 Updated by following about 7 years ago

Weitere Diskussion: http://forum.opencaching-network.org/index.php?topic=3129.0

Workaround: https://github.com/bohrsty/oc-server3/commit/8ea1c08fdd8dff53ac9dd1516f4c0cc1fd1448fa

Email dazu:

der aktuelle standort eines krety wird jetzt wieder (der code war vorher
auskommentiert) aus der "item"-information genommen, sodass hier keine
falschen angaben mehr entstehen sollten, wenn die jungs nichts falsches
liefern... ;)

#13 Updated by following about 7 years ago

Bist du dir sicher, dass die Inkonsistenzen durch fehlende Move-Datensätze entstanden sind, oder ist es nur eine Vermutung? Es könnten ja auch Daten komplett fehlen, nicht nur bei den Moves. Wenn tatsächlich Moves fehlen, bliebe das Problem dass unsere Move-Tabelle unvollständig ist.

So oder so würde ich gerne die eigentliche Ursache des Fehlers beheben (lassen), und dazu einige Konsistenzprüfungen vornehmen / einbauen:

- einmalige Konsistenzprüfung für den aktuellen Datenstand von gk_item_waypoint und gk_item_move - dann wissen wir, ob der gk_item_waypoint-Importcode in importMove() immer korrekt gearbeitet hat;

- Konsistenzprüfung für alle neu importierte Daten, direkt beim Import: Für die Menge aller Item-IDs, für die 'geokret'- und 'moved'-Elemente rüberkamen, prüfen ob die Wegpunktdaten je Item in beiden übereinstimmen. Bei Inkonsistenzen Fehlermeldung ausgeben und die XML-Datei sichern.

- Konsistenzprüfung beim Import von Komplett-Dumps: Liste der Abweichungen zwischen OC.de-Datenbank und importierten Daten ausgeben.

Die ersten beiden Punkte müssten erledigt werden, bevor dein Workaround freigegeben wird. Kannst du das übernehmen?

Bei der Datumssynchronisation können noch "pathologische Fälle" auftreten:

$modifiedsince = strtotime(getSysConfig('geokrety_lastupdate', date($opt['db']['dateformat'], time()-(60*60*24*10)+1)));

Mit der 1-Sekunden-Margin funktioniert es nur, wenn zwischen Setzen von $modifiedsince und Auswerten von $_GET['modifiedsince'] maximal eine Sekunde vergeht - vorausgesetzt, Client und Server haben eine exakt synchrone Systemzeit. Auch wenn jemand den OC-Code in ner anderen Zeitzone laufen lässt (z.B. auf meinem Entwicklersystem, da ist was falsch konfiguriert ...) kann es ins Auge gehen. ;^)

Könnte man alles erschlagen indem man 12 Stunden Kulanz draufgibt.

#14 Updated by following about 7 years ago

following schrieb:

- einmalige Konsistenzprüfung für den aktuellen Datenstand von gk_item_waypoint und gk_item_move

Oops - gemeint war gk_item_waypoint und gk_move_waypoint

#15 Updated by following about 7 years ago

following schrieb:

- einmalige Konsistenzprüfung für den aktuellen Datenstand von gk_item_waypoint und gk_item_move

Oops - gemeint war gk_item_waypoint und gk_move_waypoint

Ich übernehme das mal ...

#16 Updated by bohrsty about 7 years ago

following schrieb:

Bist du dir sicher, dass die Inkonsistenzen durch fehlende Move-Datensätze entstanden sind, oder ist es nur eine Vermutung? Es könnten ja auch Daten komplett fehlen, nicht nur bei den Moves. Wenn tatsächlich Moves fehlen, bliebe das Problem dass unsere Move-Tabelle unvollständig ist.

ist eine vermutung, da der rest des codes fuer mich keine anderen fehler erkennen laesst...

- Konsistenzprüfung für alle neu importierte Daten, direkt beim Import: Für die Menge aller Item-IDs, für die 'geokret'- und 'moved'-Elemente rüberkamen, prüfen ob die Wegpunktdaten je Item in beiden übereinstimmen. Bei Inkonsistenzen Fehlermeldung ausgeben und die XML-Datei sichern.

- Konsistenzprüfung beim Import von Komplett-Dumps: Liste der Abweichungen zwischen OC.de-Datenbank und importierten Daten ausgeben.

ein komplett-import nutzt das gleiche datenformat und die gleichen funktionen wie die updates (eine moeglichkeit das vorherige loeschen einer xml-datei zu unterbinden, muss noch eingebaut werden), daher wuerde die funktion oben ausreichen...

Die ersten beiden Punkte müssten erledigt werden, bevor dein Workaround freigegeben wird. Kannst du das übernehmen?

ich werde er mir mal ansehen, evtl. komme ich mit einer nachfrage noch mal auf dich zu... kann ich den branch noch weiterverwenden, oder ist damit schon was passiert?

Bei der Datumssynchronisation können noch "pathologische Fälle" auftreten:

$modifiedsince = strtotime(getSysConfig('geokrety_lastupdate', date($opt['db']['dateformat'], time()-(60*60*24*10)+1)));

Mit der 1-Sekunden-Margin funktioniert es nur, wenn zwischen Setzen von $modifiedsince und Auswerten von $_GET['modifiedsince'] maximal eine Sekunde vergeht - vorausgesetzt, Client und Server haben eine exakt synchrone Systemzeit. Auch wenn jemand den OC-Code in ner anderen Zeitzone laufen lässt (z.B. auf meinem Entwicklersystem, da ist was falsch konfiguriert ...) kann es ins Auge gehen. ;^)

Könnte man alles erschlagen indem man 12 Stunden Kulanz draufgibt.

hier wird ja nur der zeitstempel der letzten synchronisation aus der sysconfig ausgelesen und $_GET sollte bei den cron-jobs gar keine verwendung haben... der zweite parameter der getSysConfig() ist der defaultwert, der (vermutlich) verwendet wird, wenn in der tabelle nichts steht, der einsekunden margin ist nur eine sicherheit, damit die 10 tage definitiv nicht ueberschritten werden, falls der wert in der tabelle fehlen sollte...

#17 Updated by following about 7 years ago

bohrsty schrieb:

ein komplett-import nutzt das gleiche datenformat und die gleichen funktionen wie die updates (eine moeglichkeit das vorherige loeschen einer xml-datei zu unterbinden, muss noch eingebaut werden), daher wuerde die funktion oben ausreichen...

Es geht um zwei verschiedene Prüfungen: Die erste prüft, ob es innerhalb eines XML-Jobs (Update oder Komplettdump) Inkonsistenzen zwischen den Geokrety- und Moved-Einträgen gibt. Die zweite prüft ob der Komplettdump Daten enthält, die in der OC.de-Datenbank fehlen, d.h. ob zwischendurch irgendwelche Updates gar nicht angekommen sind. Letzteres ist etwas aufwändiger, aber ich denke es ist nötig um sicherzugehen, dass das Problem tatsächlich behoben ist.

An der Konsistenzprüfung gk_item_waypoint vs. gk_move_waypoint - also für die aktuell vorhandenen Daten - bin ich gerade dran, bin gespannt was dabei rauskommt.

kann ich den branch noch weiterverwenden, oder ist damit schon was passiert?

Kannst du weiterverwenden. Das Prüftool für gk_item_waypoint vs. gk_move_waypoint schreibe ich separat vom Cronjob.

der einsekunden margin ist nur eine sicherheit, damit die 10 tage definitiv nicht ueberschritten werden, falls der wert in der tabelle fehlen sollte...

Klar. Nur wenn die Systemuhren von Server und Client dann um mehr als eine Sekunde abweichen, oder wenn es ein Netz/Server-Hänger von über einer Sekunde gibt, können es trotzdem über 10 Tage werden und das Script fällt auf die Nase.

#18 Updated by following about 7 years ago

Der Vergleich von gk_item_waypoint mit gk_move_waypoint (-> util2/geokrety/check-waypoints.php) hat mehrere tausend Inkonsistenzen zu Tage gefördert; die komplette Liste hänge ich mal unten an. Habe mir mehrere Fälle angeschaut, und das Schema ist immer wieder das gleiche:

1. Geokret wird in Cache A geloggt
2. Geokret wird in Cache B nachgeloggt, also datemoved 2 < datemoved 1
3. Die Moves stehen korrekt in gk_move/gk_move_waypoint (hab mit Geokrety.org-Orginaldaten verglichen), aber in gk_item_waypoint steht Cache B statt A.

Wie ist das möglich? In importMove() wird korrekt nach datemoved sortiert, die Logreihenfolge sollte also keine Rolle spiele. Das Problem tritt sogar bei Nachlogs mit Typ 5 auf ("dropped") auf - z.B. bei item ID 33362 -, aber diese Logs werden doch von importMove() ignoriert!? Es betrifft aktuelle Daten, kann also nicht an einem Fehler bei einem alten Import liegen.

Außerdem: Warum hat Oliver den Item-Wegpunktimport auf die kompliziertere Methode über die Moves umgestellt? Könnte es sein, dass es auch mit der alten Methode Probleme gab, die er damit beheben wollte?

Der Konsistenzcheck der XML-Daten sollte sich damit erledigt haben. Ich werde jetzt den Inhalt von gk_item_waypoint anhand der Move-Daten korrigieren und deinen Fix freigeben. Danach kann ich mit check-waypoints.php prüfen, ob neue Inkonsistenzen auftreten oder nicht.

Ich denke der Abgleich mit dem Komplettdump - mit oder ohne Moves - macht unabhängig davon Sinn, um die von Oliver beobachteten Probleme zu verifizieren oder auszuschließen.

#19 Updated by following about 7 years ago

#20 Updated by following about 7 years ago

GK0004 fehlt in der Tabelle gk_item_waypoint, obwohl es keine verdächtigen Nachlogs gab. Laut gk_move/gk_move_waypoint & geokrety.org liegt es in OP0544. Wtf!?

#21 Updated by following about 7 years ago

ganz oben:

In OCE5C1 wird das Geokret "A sio!" angezeigt, das aber laut Geokrety-History und Daten auf geokrety.org nicht in dem Cache ist.

Ursache ist, dass bei diesem Cache "WGS84" als Navicache-Wegpunkt eingetragen ist. Der Pseudo-Wegpunkt WGS84 wird bei Geokrets verwendet, um Koordinaten statt Wegpunkte zu loggen; dadurch tauchten immer wieder mal Geokrets in diesem Cache auf die dort nicht hingehören.

Insgesamt 10 GC-Wegpunkte und 7 NC-Wegpunkte haben den Inhalt "WGS84", und bei allen werden die gleichen Geokrets angezeigt. Die Wegpunkte werde ich nun alle entsorgen. Die Eingabe "WGS84" sollte in Zukunft verhindert werden; siehe #86.

#22 Updated by following about 7 years ago

Waaaaahhh!

Dein Fix funktioniert nicht, weil in geokrety.waypoints nicht drinsteht wo sich das Kret im Moment befindet, sondern wo es zuletzt geloggt wurde (oder sowas ähnliches). Vor allem bei Logtype 5 ist diese Information falsch. Evtl. könnte die Auswertung von geokrety.status helfen, aber ich habe stattdessen nun den Wegpunkt-Import in importMove() korrigiert. Da war tatsächlich ein Bug bei Nachlogs drin.

Damit ist die Ursache der meisten Inkonsistenzen nun beseitigt, aber nicht solche Fälle wie in Kommentar Nr. 20 oben.

Nach dem Korrekturdurchlauf (util2/geokrety/fix-waypoints.php) hat gk_item_waypoint nun 3000 zusätzliche Einträge. Die Konsistenzprüfung per check-waypoints.php läuft jetzt einmal pro Stunde per Cronjob - mal schauen, was passiert.

Ich denke wir sollten auf jeden Fall noch den Komplettimport bzw. -Abgleich machen. Einfache Lösung: Cronjob abschalten, die gk_-Tabellen sichern, neu aufbauen und dann die alten und neuen Inhalte vergleichen. Falls es Unterschiede gibt: Das Ganze in ein paar Monaten wiederholen, um zu prüfen ob neue Inkonsistenzen entstehen.

Außerdem muss noch geklärt werden, in welcher Reihenfolge Geokrety.org Move-Logs mit gleichem 'datemoved' verarbeitet. Sowas kommt vor, wenn jemand innerhalb einer Minute mehr als einen Move für das gleiche Kret eingibt. Denkbar wäre eine Ordnung nach Logdatum oder nach Move-ID oder gar keine, sprich zufällig (das wäre ein Bug). Kannst du das mit den Geokrety-Leuten klären?

#25 Updated by bohrsty about 7 years ago

following schrieb:

Dein Fix funktioniert nicht, weil in geokrety.waypoints nicht drinsteht wo sich das Kret im Moment befindet, sondern wo es zuletzt geloggt wurde (oder sowas ähnliches). Vor allem bei Logtype 5 ist diese Information falsch. Evtl. könnte die Auswertung von geokrety.status helfen, aber ich habe stattdessen nun den Wegpunkt-Import in importMove() korrigiert. Da war tatsächlich ein Bug bei Nachlogs drin.

oha... einige sachen sollte man nicht testen, wenn man offline ist... und fuers echte fehlersuchen vorallem mit den nicht ganz einfachen sql-befehlen bin ich wohl nicht genug entwickler (bzw. es fehlt an erfahrung)... ich bleibe wohl mal lieber bei kleinen neuen features oder dem umschreiben der lib1 (falls ich da endgueltig durchsteige) ;)

Damit ist die Ursache der meisten Inkonsistenzen nun beseitigt, aber nicht solche Fälle wie in Kommentar Nr. 20 oben.

vielen dank schon mal...

Ich denke wir sollten auf jeden Fall noch den Komplettimport bzw. -Abgleich machen. Einfache Lösung: Cronjob abschalten, die gk_-Tabellen sichern, neu aufbauen und dann die alten und neuen Inhalte vergleichen. Falls es Unterschiede gibt: Das Ganze in ein paar Monaten wiederholen, um zu prüfen ob neue Inkonsistenzen entstehen.

Außerdem muss noch geklärt werden, in welcher Reihenfolge Geokrety.org Move-Logs mit gleichem 'datemoved' verarbeitet. Sowas kommt vor, wenn jemand innerhalb einer Minute mehr als einen Move für das gleiche Kret eingibt. Denkbar wäre eine Ordnung nach Logdatum oder nach Move-ID oder gar keine, sprich zufällig (das wäre ein Bug). Kannst du das mit den Geokrety-Leuten klären?

ich warte noch auf antwort von den jungs, sobald ich den komplettexport habe, gucken wir mal weiter... dann frage ich auch mal nach der reihenfolge und warum GK8650 das doppellog hat (bug?)...

#26 Updated by following about 7 years ago

  • Status changed from offen to im Test

Livetest, bislang ohne Probleme

#27 Updated by following about 7 years ago

  • Status changed from im Test to erledigt

#28 Updated by following about 7 years ago

  • Status changed from erledigt to in Arbeit 20%

oops, fehlt ja noch der Komplettabgleich

#30 Updated by Lineflyer over 5 years ago

Hallo!
Ich bin ein Mitglied des c:geo Entwicklerteams und gerade dabei die neue Geokret-Implementierung zu testen.
Hierbei ist auch eine Inkonsistenz zwischen den Geokret-Daten bei GK und OC aufgefallen.

Mehr Infos und ein Beispiel hier:
https://github.com/cgeo/cgeo/issues/4781

Ist dies dasselbe Problem?

#31 Updated by following about 5 years ago

Lineflyer schrieb:

Ist dies dasselbe Problem?

Vermutlich ja. In letzter Zeit sind wieder Inkonsistenzen aufgetreten. Hab eben mal das Reparaturscript drüberlaufen lassen, aber das behebt nur interne Inkonsistenzen zwischen gk_item_waypoint und gk_move_waypoint. Es wird nach wie vor ein Komplettabgleich mit den Originaldaten benötigt, oder wir verzichten auf (Vollständigkeit von) gk_move_waypoint.

#32 Updated by following about 5 years ago

  • Assignee changed from bohrsty to following

Ich baue eine Archivierungsoption für die heruntergeladenen XML-Dateien ein. Damit sollte sich die Ursache der Inkonsistenzen herausfinden lassen.

#33 Updated by following about 5 years ago

In den Tabellen backup_gk* ist der momentane Stand der gk-Tabellen gesichert, und alle weiteren XML-Imports bleiben in cache2/geokrety liegen (Geokrety-XML-Archivierung aktiviert in settings.inc.php).

#34 Updated by following over 4 years ago

  • Assignee deleted (following)

Also available in: Atom PDF