Nochmal ein Update. Einer der JOSM-Entwickler hat in https://josm.openstreetmap.de/ticket/22160#comment:38 folgendes vorgeschlagen:
*
Falls jemand Java 11 oder neuer einsetzt und aktuell das Problem mit einer offiziellen JOSM-Version gut nachstellen kann, sollte einmal das “http2” Plugin installieren und dann probieren, ob das Problem weiterhin auftritt.*
Anmerkung der Redaktion: den Teil zu Java 11 habe ich aus der Beschreibung des Plugins (“Provides HTTP/2 support. Requires Java 11 or later.”) ergänzt. Das steht so explizit nicht im Ticket drin.
Wer nicht weiß, welche Java-Version gerade zum Einstaz kommt: im Menü unter Hilfe → Statusbericht anzeigen (oder “Show status report”) gibt es weitere Infos. Recht weit oben sollte dort eine Zeile beginnend mit “Java version: …” zu finden sein.
Das habe ich heute realisiert und für einige UPloads kein Problem mehr festgestellt. Es wäre wünschenswert, wenn weitere Anwender das ausprobieren würden …
Ich kann das aktuell nicht testen/provozieren, aber wenn’s der Wahrheitsfindung dient, kann ich sehr sicher ausschliessen, dass ich die Probleme mit Java 9 oder 10 schon hatte.
Bei mir läuft das http2-Plugin seit gestern und nun trat der Fehler das erste Mal wieder auf.
JOSM-tested 18463
openjdk version “11.0.15” 2022-04-19
OpenJDK Runtime Environment (build 11.0.15+10-suse-150000.3.80.1-x8664)
OpenJDK 64-Bit Server VM (build 11.0.15+10-suse-150000.3.80.1-x8664, mixed mode)
“Früher” (ohne http2) kam der Fehler immer vor UPload der ersten Änderung.
Jetzt (mit http2) kommt der GOAWAY Fehler (in meinem Beipiel) nach Hochladen von 9 von 65 Änderungen.
Liefert dieser Unterschied Erkenntnisse in Bezug auf die von mmd beschriebenen UPload-Schritte?
Dazu hätte ich eine Frage. Wie genau hast du dein JOSM konfiguriert?
Falls du jedes Objekt einzeln hochlädst (“Upload each object individually”, dritter Radiobutton), dann kommt in JOSM anstelle von Schritt (3) ein anderer Mechanismus zum Einsatz. Dafür gibt es dann die Element-basierten Endpunkte (link), die ebenfalls über Ruby on Rails laufen.
Falls du jedoch den zweiten Radiobutton (“Upload objects in chunks of size” mit dem Wert 1) nutzt, dann gilt wieder mein Punkt (2).
Kannst du vielleicht einen Screenshot zur Verfügung stellen, wie genau deine Einstellungen zum Hochladen der Daten aussehen?
Ok, danke, das wäre dann der “Element-basierte” Upload, der auch über Ruby on Rails läuft.
Nebenbei: generell empfehle ich, die Änderungen in einem Schritt hochzuladen. Auch 10’000 Änderungen in einem Schritt sind kein Problem für die API. Zum einen ist das deutlich flotter, zum anderen gibt es dann weniger Probleme mit Konflikten.
Wenn ich jetzt 64 Objekte einzeln hochlade, und nach 63 Objekte kommt es dann zu einem Konflikt, sind 63 Objekte bereits auf der Datenbank und ich muss dann versuchen, irgendeinen inkonsistenten Zustand nochmal zu reparieren. Das ist alles eher weniger schön.
Wenn ich allerdings alles in einem Schritt hochlade und es kommt dabei zu einem Konflikt, werden keine Änderungen auf die Datenbank geschrieben. Ich kann jetzt in aller Ruhe den Konflikt lokal beheben und danach den Upload einfach nochmal versuchen.
Vor (1) fragt JOSM noch nach offenen Änderungssätzen des Nutzers: link
Danke, gut zu wissen!
Auf dem Dev-Server konnte ich das Problem leider nicht reproduzieren.
Das OAuth mit den angegebenen Daten hat der Server übrigens bei mir nicht akzeptiert, habe dann ein eigenes Benutzerkonto erstellt: https://josm.openstreetmap.de/ticket/22160#comment:31
Bei HTTP/2 gibt es also vom Server die Ankündigung “GOAWAY”, bevor dieser dann wie bisher auch das TCP-FIN zum Schließen der Verbindung sendet.
Das GOAWAY verwertet JOSM dann wohl aber auch nicht.
Nachdem ich mir jetzt auch das HTTP2-Plugin für JOSM installiert habe und ausgiebig getestet habe:
Auch beim Herunterladen von Notes (https://api.openstreetmap.org/api/0.6/notes…) bekomme ich manchmal “GOAWAY” und aber immer nur dann, wenn zwischen zwei Abfragen ca. 4-6 Sekunden liegen. Frage ich deutlich schneller oder langsamer ab, bekomme ich kein GOAWAY.
Nach Auswertung von Wireshark und JOSM-Logs läuft das immer nach folgendem Schema ab:
Verbindungsaufbau
Up- oder Download von der OSM-API
OSM-Server beendet die Verbindung mit GOAWAY, gefolgt von einem TCP-FIN.
Gleichzeitig bzw. weniger als eine Millisekunde davor (die Zeitnahme ist vermutlich auch nicht 100%-ig genau) oder danach versucht JOSM über die inzwischen geschlossene Verbindung Daten zu senden, was dann fehlschlägt.
JOSM behandelt diesen Fall dann nicht korrekt.
Genau da scheint also das Problem zu sein.
Bei erstmaligen Verbindungen zur API tritt der Fehler nie auf, erst wenn JOSM versucht eine bestehende Verbindung nochmal zu verwenden, nachdem sie kurz davor geschlossen wurde. Also so etwas wie ein Time-of-Check-to-Time-of-Use-Problem: https://de.wikipedia.org/wiki/Time-of-Check-to-Time-of-Use-Problem
JOSM bzw. Java sehen nach, ob die Verbindung zur API noch besteht, falls das der Fall ist, versucht JOSM diese wiederzuverwenden, bis dann aber JOSM die Verbindung verwendet, wurde diese zwischenzeitlich geschlossen. Diesen Fall behandelt dann JOSM nicht korrekt.
Das ist sehr interessant, der Wert liegt verdächtig nahe am Keep-Alive timeout von 5 Sekunden, den ich in den Traces von MichaelFS im Ticket gesehen habe (das war allerdings noch mit HTTP/1.1)
Wenn das doch bloß 'ne simple race condition sein sollte, dann wundert mich, daß es bisher noch keine Probleme gab. Auf jeden Fall sollte der Code JOSM doch eine Callback-Funktion registrieren (oder wie man Vergleichbares in Java auch immer macht), damit es mitbekommt, wenn ihm zwischenzeitlich die Verbindung wegfliegt.