JOSM: kann keine Änderungen mehr hochladen!?

aighes · 2010-12-20T14:31:36.000Z

Bei mir läufts…aber ich mach jetzt mal Kaffeepause… also nur zu…

Es gibt nur 2 Server, die die API stemmen, wie die sichd ie Arbeit aufteilen weiß ich allerdings nicht, ich vermute mal, dass das nach Last geht.

EvanE · 2010-12-20T15:01:25.000Z

koppenho:

…

Etwas irritiert mich im Changeset 6715385 die Angabe “Für dieses Changeset wurde kein Bereich gespeichert.”.
Ist das der Fehler? Wenn Ja, wodurch kann so etwas ausgelöst werden und wie behebe ich das Problem?

Kann das an meinen Änderungen liegen? 58 Objekte, aus meiner Sicht nichts ungewöhliches dabei.

Hallo Andreas

Das passiert wenn ein Changeset geöffnet wird, jedoch keine Daten hochgeladen wurden.
Dann gibt es nichts anhand dessen man einen Bereich identifizieren könnte.

Sicher nicht das was du wolltest, aber wenn ein Upload nicht ging, durchaus normal.

Edbert (EvanE)

koppenho · 2010-12-20T15:48:18.000Z

Inzwischen konnte ich feststellen, dass meine Upload-Probleme von meinen Änderungen verursacht werden.
Wie das sein kann, konnte ich nicht ermitteln.
Einige haben mir berichtet, dass das an Objekten liegen könne, die in einer sehr großen Relation stecken. Der OSM-Server würde dafür z.T. sehr lange benötigen.
Das trifft hier nicht zu.
Ich habe eine einzelne modifizierte Node selektiert und “Datei->Auswahl hochladen” gestartet.
Das funktionierte für viele Nodes nicht. Warum ist mir rätselhaft.

Ich gebe an dieser Stelle auf. Ist mir zu zeitintensiv.
Mein Workaround sieht so aus:

reverter plugin installieren und die bereits hochgeladenen Teile zurücksetzen. Betrifft 4 Changesets bei denen tatsächlich etwas hochgeladen wurde. 2 davon kann ich lassen. Muss also nur 2 zurücksetzen.

alle Änderungen wegwerfen und nochmal anfangen.

Schrittweise heranpirschen: jede kleine Änderung sofort hochladen in der Hoffnung, dass ich so die Ursache besser erkennen kann.

Dank an alle, die mir Tipps gegeben haben.

EvanE · 2010-12-20T16:05:40.000Z

koppenho:

…
Mein Workaround sieht so aus:

…

Schrittweise heranpirschen: jede kleine Änderung sofort hochladen in der Hoffnung, dass ich so die Ursache besser erkennen kann.

Dank an alle, die mir Tipps gegeben haben.

Noch ein kleiner vielleicht unwichtiger Tipp:
Du kannst bei JOSM einstellen, ob er das Changeset noch dem Upload schliessen soll (also für jede Änderung ein eigenes Changeset erstellen soll) oder ob das Changeset geöffnet bleiben soll (also weitere Uploads in das gleiche Changeset gehen).

Letzteres mach Sinn, wenn die Änderungen im Grunde zusammen gehören.
Wie auch immer, es ist deine Sache wie du das handhabst.

Edbert (EvanE)

koppenho · 2010-12-20T16:12:51.000Z

EvanE:

Du kannst bei JOSM einstellen, ob er das Changeset noch dem Upload schliessen soll (also für jede Änderung ein eigenes Changeset erstellen soll) oder ob das Changeset geöffnet bleiben soll (also weitere Uploads in das gleiche Changeset gehen).

Letzteres mach Sinn, wenn die Änderungen im Grunde zusammen gehören.

Danke für den Tipp - werde ich ausprobieren.
Ich hatte bisher noch nicht verstanden, weshalb man überhaupt ein Changeset offen lassen soll… aber jetzt ist der Groschen gefallen.

Dieses Vorgehen erscheint mir sehr sinnvoll für größere Änderungen…

koppenho · 2010-12-20T20:52:48.000Z

koppenho:

EvanE:

Du kannst bei JOSM einstellen, ob er das Changeset noch dem Upload schliessen soll (also für jede Änderung ein eigenes Changeset erstellen soll) oder ob das Changeset geöffnet bleiben soll (also weitere Uploads in das gleiche Changeset gehen).

Letzteres mach Sinn, wenn die Änderungen im Grunde zusammen gehören.

Danke für den Tipp - werde ich ausprobieren.

Hat leider nicht funktioniert.
Die Ursache, weshalb ich keine Änderungen mehr hochladen kann, liegt an folgenden Nodes:
http://www.openstreetmap.org/browse/node/1013462815
http://www.openstreetmap.org/browse/node/1013462707
http://www.openstreetmap.org/browse/node/1013462778
http://www.openstreetmap.org/browse/node/1013462615
http://www.openstreetmap.org/browse/node/1013462735

Sie gehörten zu einer geschlossenen Fläche, die das Gebäude der Sparkasse darstellen sollte.
Wegen der schon berichteten Probleme mit den oben genannten nodes konnte ich die Erfassung des Gebäudes nicht korrigieren/verbessern. Änderungen an den nodes waren mir nicht möglich.

Daher habe ich beschlossen den dazugehörigen way
http://www.openstreetmap.org/browse/way/87158717
und alle seine Punkte zu löschen. Damit hatte ich leider nur einen Teilerfolg.
Mit den letzten 5 Punkten komme ich nicht weiter.

Was ist mit diesen nodes nur los?
Wie schafft man es “immutable nodes” zu setzen?
Weshalb kann ich diese Biester nicht löschen oder ändern (weder mit JOSM noch mit Potlatch)?
Datenbankfehler?

In der Mailingliste de-talk habe ich gefragt, ob jemand diese nodes für mich löschen kann.

SunCobalt · 2010-12-20T21:11:45.000Z

witzig. Ich kriege die auch nicht weg. Wenn Du es weißt, sagst Du dann woran es lag? Das interessiert mich auch

aighes · 2010-12-20T21:21:39.000Z

In der Tat…Potlatch löscht auch nicht…

BBO · 2010-12-20T21:23:17.000Z

Ich hatte auch keinen Erfolg…

koppenho · 2010-12-20T22:01:26.000Z

SunCobalt:

Wenn Du es weißt, sagst Du dann woran es lag? Das interessiert mich auch

Klar, mach’ ich.
Vorher muss ich aber noch jemand finden, der das Problem analysieren kann…

kellerma · 2010-12-20T22:45:29.000Z

Hi,

hab’ 2 gelöscht, die anderen nkbre & daswaldhorn.

Ciao,
Frank

EvanE · 2010-12-20T22:48:53.000Z

koppenho:

SunCobalt:

Wenn Du es weißt, sagst Du dann woran es lag? Das interessiert mich auch

Klar, mach’ ich.
Vorher muss ich aber noch jemand finden, der das Problem analysieren kann…

Nu sind sie weg.

Potlatch2 sagte:

Version mismatch
Version 1 soll gelöscht werden, Version 2 existiert aber bereits
Try to delete already deleted objekt (mehrfach)

Es bleibt seltsam. Aber wenigstens sind sie weg.

Edbert (EvanE)

kellerma · 2010-12-20T23:41:42.000Z

aighes:

Es gibt nur 2 Server, die die API stemmen, wie die sichd ie Arbeit aufteilen weiß ich allerdings nicht, ich vermute mal, dass das nach Last geht.

Mmh, puff+fuchur; schaut eher wie einfaches Round Robin DNS aus:

nslookup api.openstreetmap.org

Name: api.openstreetmap.org
Addresses: 128.40.168.105, 128.40.168.98

Ciao,
Frank

BBO · 2010-12-21T07:15:44.000Z

Die Lösung aus der ML:

Das war ein Bug im Backend. Da bleiben manchmal - sehr selten und unter
bislang ungeklaerten Umstaenden - Diff-Uploads haengen und blockieren
sich gegenseitig. Man sieht das an diesem Bild ganz gut:

http://munin.openstreetmap.org/openstreetmap/smaug.openstreetmap/postgres_locks_openstreetmap.html

Wenn so ein Request erstmal haengt, gibt er die Transaktions-Locks in
der Datenbank nicht frei, und alles, was eines von den in der
Transaktion veraenderten Objekten anfasst, bleibt dann auch ewig haengen
(und beansprucht zusaetzliche Locks - das ist der Berg auf dem Bild).

Wie man ebenfalls an dem Bild sieht, passiert das bloss alle paar Monate
mal. Aber wenn es passiert, dann muss ein Admin der Kiste einen Tritt
geben - wie jetzt gerade auf meine Nachfrage hin geschehen. Und
schwupps, waren die Nodes auch schon weg.

Bevor jemand aber jetzt in der Zukunft bei jedem Upload, der mal etwas
laenger dauert, so ein Lock-Problem vermutet - immer erst mal auf diese
Munin-Grafik schauen, bevor man Alarm schreit

Bye
Frederik

kellerma · 2010-12-21T09:42:09.000Z

Naja, die Buerde, die RRD-Graphen der locks der Datenbak zu beobachten, kann man kaum den mapper “von der Strasse” auferlegen.
Dies ist klar eine Aufgabe fuer Serveradmins. …

Ciao,
Frank

bjoernchr74 · 2011-02-10T07:12:53.000Z

Moin,

Ich habe gestern hier tonnenweise Änderungen gemacht in JOSM und wollte die dann hochladen. Hat “gehangen”. Also nochmals probiert, nochmal usw. Dann bin ich hier auf einen Thread gestoßen, wonach das Problem wohl die DB ist - da ich Sachen ändere die bereits existieren.

Nun gucke ich also hier: http://munin.openstreetmap.org/openstreetmap/smaug.openstreetmap/postgres_locks_openstreetmap.html

Und man sieht da schon WARN/CRIT Fehler… ist das dieses Problem was hier geschildert wird? Ätzend ist nämlich, daß meine Änderungen nun bereits x-fach in der DB sind Wenn es das Problem ist - wer kann den “Admin” antriggern? Ich würde das gerne einchecken bevor jemand anderes Änderungen macht sonst dreh ich durch Ach ja - und ich habe gestern abend ca. 3 Stunden gewartet bis der Upload fertig ist - und es hatte nicht geklappt…

mdk · 2011-02-10T09:53:55.000Z

Ich weiss nicht ob meine Beobachtung relevant ist, aber ich habe auch öfters Probleme beim Hochladen, aber nur wenn ich JOSM unter Windows benutze.

Windows:

Nach dem Start des Uploads erscheint nach einiger Zeit im Dialog eine Medung, dass neue Versuche gestartet werden (1 von 5 usw.)
Bei einigen hundert geänderten Objekten klappt es dann irgendwann.
Bei grösseren Changesets kommt es dann zum Abbruch. Mit einigen Wiederholungen (“Aktualisiere ChangeSet xy”) funktioniert es dann auch.
Danach kommt häufig eine Meldung, dass noch ein Objekt synchronisiert werden muss, was aber in der Regel zu keinem Konflikt führt.
Am Ende muss man noch das offen gebliebene Changeset schliessen (oder warten, bis es automatisch geschlossen wird)
Die Probleme treten weitgehend unabhänig von der Serverlast auf.

Ubunu:

Trotz hoher Serverlast funktioniert der Upload meist ohne Probleme
Die Meldung, dass ein neue Versuch gestartet wird, erscheint eigentlich nie (zumindest kann ich mich nicht daran erinnern)
Eine Synchronisation am Ende ist eigentlich nie nötig (ausser es ist wirklich ein Konflikt da)

Vermutung:
Der Netzwerkmonitor zeigt an, das JOSM alle Änderungen auf einmal hochläd und danch kein Netzwerktraffik mehr ist. Der Server verarbeitet nun das Changeset. Wenn er mit der Überprüfung fertig ist, sendet er eine Antwort an JOSM zurück. Meines Wissens hat Windows defaulmässig ein Timeout von 30 Sekeunden für seine Sockets. Kommt innerhalb dieser Zeit keine Antwort auf eine HTTP Anfrage, wird der Socket geschlosen und JOSM erhält einen Fehler. JOSM probiert in solch einem Fall eine neue Verbindung aufzubauen. Der Server erkennt aber, dass es sich um ein bekanntes Changeset handelt und behandelt es als “update” des Changesets.
Ubuntu hat dort (soweit ich weiss) ein längeres Timeout, so dass trotz hoher Serverlast der Update durchkommt.

Die Beobachtung, dass bei der Zerlegung des Changesetz in kleine Teile (z.B. je 10 Objekte) sich die Situation bessert, wäre damit auch erklärt: Der Server antwortet nach erfolgreicher Verarbeitung des Päckchens und fordert das nächste an. Dadurch würde der Timeout vermiden werden.

Generell könnte man das Problem vermutlich lösen, indem der Server mit der Antwort nicht wartet, bis er mit der Verarbeitung fertig ist, sondern bereits vorher (z.B. nach 10 Sekunden) eine Antwort (“bin noch nicht fertig”) an JOSM zurücksendet. JOSM müsste dann so lange weitere Request (“ok, ich warte noch”) senden, bis der Server seine Aufgabe erledigt hat. Dies würde aber eine Erweiterung der API bedeuten, da alte JOSM-Versionen damit vermutlich nicht damit klar kämen.

mdk

bjoernchr74 · 2011-02-10T20:53:30.000Z

Also was ich gemacht hatte war, daß ich auf “einzelne Uploads” geändert habe - d.h. es sollten 738 einzelne Änderungen hochgeladen werden. Ich konnte dann sehen, daß es IMMER bei der Änderung ein und des gleichen bestehenden Eintrages zum hängen kam. Ich habe dann heute morgen versucht einen anderen zu ändern - ging auch nicht. UPDATES klappen nicht, wohl aber INSERTS da sämtliche von mir neu angelegten Hausnummern perfekt gingen… Argh.

SunCobalt · 2011-02-10T21:23:35.000Z

bjoernchr74:

Also was ich gemacht hatte war, daß ich auf “einzelne Uploads” geändert habe - d.h. es sollten 738 einzelne Änderungen hochgeladen werden. Ich konnte dann sehen, daß es IMMER bei der Änderung ein und des gleichen bestehenden Eintrages zum hängen kam.

Ähm, wenn Du im Upload Dialog auf Erweitert->“Jedes Objekt einzeln hochladen” wechselst, da siehst Du ja, wieviel bereits hochgeladen ist. Gibt es ein Problem, speichere nach dem abgebrochenen Upload-Versuch. Lädst Du wieder eine frühere Version, erzeugst Du unerwünschte Dup(licate)Nodes, da auch die bereits erfolgreich hochgeladenen Nodes nochmal hochgeladen werden.

bjoernchr74:

Ich habe dann heute morgen versucht einen anderen zu ändern - ging auch nicht. UPDATES klappen nicht, wohl aber INSERTS da sämtliche von mir neu angelegten Hausnummern perfekt gingen… Argh.

Was meinst Du? Ich verstehe es nicht

bjoernchr74 · 2011-02-10T22:30:07.000Z

SunCobalt:

bjoernchr74:

Also was ich gemacht hatte war, daß ich auf “einzelne Uploads” geändert habe - d.h. es sollten 738 einzelne Änderungen hochgeladen werden. Ich konnte dann sehen, daß es IMMER bei der Änderung ein und des gleichen bestehenden Eintrages zum hängen kam.

Ähm, wenn Du im Upload Dialog auf Erweitert->“Jedes Objekt einzeln hochladen” wechselst, da siehst Du ja, wieviel bereits hochgeladen ist. Gibt es ein Problem, speichere nach dem abgebrochenen Upload-Versuch. Lädst Du wieder eine frühere Version, erzeugst Du unerwünschte Dup(licate)Nodes, da auch die bereits erfolgreich hochgeladenen Nodes nochmal hochgeladen werden.

Ok - d.h. also ich muß, wenn das passiert, “sichern” - damit würde JOSM dann die wo es geklappt hat als “alt” speichern und nicht mehr hochladen danach? Gut, daß wußte ich nicht. In der Tat gab es einige Dups, hab die gerade mal überarbeitet und soweit ich sehe gefixed… Und ein Bot hat ebenfalls heute nachmittag viele gefixed.

Da sollte aber JOSM mal verbessert werden - wenn der Upload teilweise ging sollte es den Anwender drauf hinweisen, daß man speichern sollte vor dem nächsten Upload wegen der Gefahr von Inkonsistenzen…

SunCobalt:

bjoernchr74:

Ich habe dann heute morgen versucht einen anderen zu ändern - ging auch nicht. UPDATES klappen nicht, wohl aber INSERTS da sämtliche von mir neu angelegten Hausnummern perfekt gingen… Argh.

Was meinst Du? Ich verstehe es nicht

Was ich meine ist: Ich habe tonnenweise neue Hausnummern angelegt. Diese wurden anscheinend korrekt hochgeladen - es hat ja erst bei Objekt 580 oder so das Problem gegeben (da hatte ich dann angefangen bestehende Objekte zu ändern). Das Einfügen neuer Daten ist ja ein “INSERT” in die Datenbank - das ging super. Der “UPDATE” zum Ändern der bestehenden Daten (ab Objekt 580) ging jedoch nicht.