Api Probleme

Das habe ich auch nicht bestreiten wollen. Ich kenne die Arbeit in der Softwareentwicklung. Und ich denke, dass diese Teams Profiarbeit auch für 0€ leisten. Aber es kann auch nicht sein, dass plötzlich auftretende Fehler nicht beseitigt werden. Es muss ja nicht von jetzt auf gleich passieren. Aber es muss Signale geben, dass man daran arbeitet. Und wenn Restriktionen eingeführt werden, weil die Serverkapazität oder die Bandbreite oder oder oder nicht mehr ausreicht, dann muss das kommuniziert werden. Dann kann man sich darauf einstellen. Ich kenne nicht die finanziellen Möglichkeiten von OSM, kann mir aber vorstellen, dass man dort nicht wie der Herr Musk mit den $s so um sich werfen kann. Auch wenn die Resourcen knapp werden. Aber auch das sollte bekannt gemacht werden.

Also prinzipiell werkeln da 3 Frontend-Server, die ausreichend Kapazität haben müssten (CPU->Langeweile, Memory=25% belegt). Ich sehe auch nicht in prometheus, dass wir irgendwelche Lastspitzen haben, was die Zahl der Verbindungen angeht. Die Anfragen laufen im konkreten Fall über Apache und Phusion Passenger für Ruby on Rails. Es gibt also genügend Komponenten, die lustige Sachen anstellen könnten.

Inzwischen gibt es einen ersten Patch für JOSM. Mal schauen, ob damit das Problem gelöst wird, ohne dass neue Probleme entstehen (z.B. mehrfache Uploads derselben Daten).

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.

Na ja, am Samstag hatte ich Null Upload-Probleme, während zu manchen Zeiten jeder zweite Upload nicht klappt…

Danke!

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 …

http2 hab ich gerade installiert.

Das http2-plugin behebt den Fehler bei mir nicht.
Die Meldung ist nun allerdings leicht anders (GOAWAY received).

Wenn meine Vermutung stimmt, dann hilft es auch nicht, da es ein Problem unterhalb von HTTP auf TCP-Ebene ist.

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.

Ich verwende Java 11 seit 2019, die Upload-Fehler kamen bei mir später. Das http2 plugin probiere ich umgehend aus und gebe bescheid.

Läuft eigentlich der Upload und der Download über die gleiche URL? Beim Download hatte ich noch nie so eine Fehlermeldung.

Die Sache ist etwas komplizierter, weil es “den Upload” so nicht gibt. Der teilt sich nämlich in folgende Schritte auf:

  • (1) Neuen Änderungssatz erzeugen: link
  • (2) Änderungssatz aktualisieren (nur für erneutes Hochladen, sofern Änderungssatz vorher nicht geschlossen wurde): link
  • (3) Diff upload (das eigentliche Hochladen der OSM Objekte): link
  • (4) Änderungssatz schließen: link

Probleme machen die Schritte (1) und (2), die auf Ruby on Rails laufen. (3) läuft auf C++, ebenso wie der Download.

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)

Fehlermeldung:

Heute hier ebenso. Ein weiterer Unterschied:

  • “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?

Jedes Objekt einzeln; hier der Screenshot:

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.

Bei mir ist der erste Radiobutton “Lade alle Objekte in einer Anfrage hoch” gesetzt:

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:

  1. Verbindungsaufbau
  2. Up- oder Download von der OSM-API
  3. OSM-Server beendet die Verbindung mit GOAWAY, gefolgt von einem TCP-FIN.
  4. 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.
  5. 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)

15:00:34.813 FEIN: RESPONSE HEADERS: {null=[HTTP/1.1 200 OK], Server=[Apache/2.4.41 (Ubuntu)], …, Keep-Alive=[timeout=5, max=100], Status=[200 OK]

Es wäre prima, wenn du deine Findings auch im JOSM Ticket posten könntest, es ist sehr relevant für unser Problem.