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.
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…
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.
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.
Ä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…
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.
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…