Api Probleme

Es ist ungewöhnlich, dass der Server eine Keepalive-Verbindung vor Ablauf des durch den Server gesetzten Timeouts, hier 5 Sekunden, schließt. Evtl. hat der Server aber ein Ressourcenprobleme und macht das deshalb oder vielleicht macht das auch eine vorgelagerte Firewall, warum auch immer.
Wie dem auch sei, das mag nicht optimal sein, aber verboten ist das nicht, JOSM muss damit rechnen und sich entsprechend verhalten.
Wenn es am von JOSM gesendeten Payload läge, würde ich eher die Rückgabe eines HTTP-Statuscodes erwarten, anstatt die Schließung der Verbindung, aber vielleicht gab es den auch, denn durch die Verschlüsselung sehe wir ihn nicht, da wird noch ein Log z.B. mit “-Djavax.net.debug=all” benötigt.

Vielleicht wird manchmal die Anzahl der möglichen offenen Server-Verbindungen überschritten und der Server schließt deshalb ungenutzte Keepalive-Verbindungen?

Das ist jetzt die Aussage des Technikers.
Wenn mir das die Telekom-Hotline erzählen würde, wäre ich schon morgen bei Vodafon.

Wir arbeiten hier alle für 0€ die Stunde für die Allgemeinheit. Und die meisten haben wohl noch andere Hobbies. Kann also sein, dass der eine oder andere morgen oder irgendwann, wenn er wieder zum x-ten Mal aufgefordert wird sein Internetverbindung zu überprüfen, zu einem seiner anderen Hobby wechselt.
Die Telekom sagt (intern), wir haben doch genug Kunden, da kommt es auf einen nicht an…

Das gilt genauso für die Leute die an der API SW arbeiten, wie auch für die JOSM Entwickler.

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.