Api Probleme

SimonPoole · 2022-06-25 16:26:27

Wetterauer wrote:

...Wir arbeiten hier alle für 0€ die Stunde für die Allgemeinheit. ...

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

Wetterauer · 2022-06-25 16:49:17

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.

mmd · 2022-06-25 18:09:05

whb wrote:

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.

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).

Last edited by mmd (2022-06-26 18:08:09)

mmd · 2022-06-27 21:22:35

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.

Last edited by mmd (2022-06-28 09:04:52)

chris66 · 2022-06-28 08:34:11

mmd wrote:

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.

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

MichaelFS · 2022-06-28 09:28:30

Danke!

mmd wrote:

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

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

chris66 · 2022-06-28 10:38:04

http2 hab ich gerade installiert.

Systemstatus wrote:

Identification: JOSM/1.5 (18463 de) Windows 10 64-Bit
Memory Usage: 370 MB / 4000 MB (102 MB allocated, but free)
Java version: 11.0.15+10, Eclipse Adoptium, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.25×1.25)
Maximum Screen Size: 1920×1080

Last edited by chris66 (2022-06-28 10:48:41)

chris66 · 2022-06-28 11:36:49

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

Java-Console wrote:

2022-06-28 12:34:11.928 SCHWERWIEGEND: Ein-/Ausgabefehler - <html>Datenübertragungsfehler zum Server "https://api.openstreetmap.org/api/0.6/" beim Hoch- oder Herunterladen. Details: /192.168.2.101:50438: GOAWAY received</html>

Last edited by chris66 (2022-06-28 12:07:26)

Fabi2 · 2022-06-28 12:44:30

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

MKnight · 2022-06-28 21:12:53

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.

mcliquid · 2022-06-29 06:23:56

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.

mmd · 2022-06-29 07:10:52

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.

Rainero · 2022-06-29 09:43:52

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:

MichaelFS · 2022-06-29 10:25:42

chris66 wrote:

Das http2-plugin behebt den Fehler bei mir nicht.
Die Meldung ist nun allerdings leicht anders (GOAWAY received).
2022-06-28 12:34:11.928 SCHWERWIEGEND: Ein-/Ausgabefehler - <html>Datenübertragungsfehler zum Server "https://api.openstreetmap.org/api/0.6/" beim Hoch- oder Herunterladen. Details: /192.168.2.101:50438: GOAWAY received</html>

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?

Last edited by MichaelFS (2022-06-29 10:28:26)

mmd · 2022-06-29 11:27:27

MichaelFS wrote:

Jetzt (mit http2) kommt der GOAWAY Fehler (in meinem Beipiel) nach Hochladen von 9 von 65 Änderungen.

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?

Last edited by mmd (2022-06-29 11:35:29)

MichaelFS · 2022-06-29 12:27:37

mmd wrote:

MichaelFS wrote:
Jetzt (mit http2) kommt der GOAWAY Fehler (in meinem Beipiel) nach Hochladen von 9 von 65 Änderungen.
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:

mmd · 2022-06-29 18:00:47

MichaelFS wrote:

Jedes Objekt einzeln;

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.

Last edited by mmd (2022-06-29 18:06:13)

whb · 2022-06-29 18:28:43

mmd wrote:

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.

Vor (1) fragt JOSM noch nach offenen Änderungssätzen des Nutzers: link

mmd wrote:

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.

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

chris66 wrote:

Die Meldung ist nun allerdings leicht anders (GOAWAY received).

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.

Rainero · 2022-06-29 21:39:58

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

whb · 2022-06-30 10:38:47

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-C … se-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.

mmd · 2022-06-30 10:54:19

whb wrote:

bekomme ich manchmal "GOAWAY" und aber immer nur dann, wenn zwischen zwei Abfragen ca. 4-6 Sekunden liegen.

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.

Fabi2 · 2022-07-01 01:06:14

whb wrote:

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-C … se-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.

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.

Last edited by Fabi2 (2022-07-01 01:30:59)

chris66 · 2022-07-01 19:37:35

Heute superschnell und ohne Errors. Wurde schon was gebastelt am Server?

SimonPoole · 2022-07-01 22:30:07

chris66 wrote:

... Wurde schon was gebastelt am Server?

Nein und es gibt auch keinen Grund dafür.

Rainero · 2022-07-02 17:45:24

Heute trat es erstmals nicht beim Hochladen auf, sondern direkt beim Neustart nach dem Aktualisieren der Plugins:

Leider habe ich kein Wireshark-Log, weil ich in dieser Phase nicht damit rechnete. Zwei weitere Neustarts mit Wireshark waren dann ohne Fehler.
Bei mir ist "kein Proxy" eingestellt.

JOSM-tested 18463 mit http2 Plugin
openjdk version "11.0.15" 2022-04-19
opensuse 15.3

Announcement

#51 2022-06-25 16:26:27

Re: Api Probleme

#52 2022-06-25 16:49:17

Re: Api Probleme

#53 2022-06-25 18:09:05

Re: Api Probleme

#54 2022-06-27 21:22:35

Re: Api Probleme

#55 2022-06-28 08:34:11

Re: Api Probleme

#56 2022-06-28 09:28:30

Re: Api Probleme

#57 2022-06-28 10:38:04

Re: Api Probleme

#58 2022-06-28 11:36:49

Re: Api Probleme

#59 2022-06-28 12:44:30

Re: Api Probleme

#60 2022-06-28 21:12:53

Re: Api Probleme

#61 2022-06-29 06:23:56

Re: Api Probleme

#62 2022-06-29 07:10:52

Re: Api Probleme

#63 2022-06-29 09:43:52

Re: Api Probleme

#64 2022-06-29 10:25:42

Re: Api Probleme

#65 2022-06-29 11:27:27

Re: Api Probleme

#66 2022-06-29 12:27:37

Re: Api Probleme

#67 2022-06-29 18:00:47

Re: Api Probleme

#68 2022-06-29 18:28:43

Re: Api Probleme

#69 2022-06-29 21:39:58

Re: Api Probleme

#70 2022-06-30 10:38:47

Re: Api Probleme

#71 2022-06-30 10:54:19

Re: Api Probleme

#72 2022-07-01 01:06:14

Re: Api Probleme

#73 2022-07-01 19:37:35

Re: Api Probleme

#74 2022-07-01 22:30:07

Re: Api Probleme

#75 2022-07-02 17:45:24

Re: Api Probleme

Board footer