Api Probleme

Auf die Gefahr hin, dass ich mich wiederhole: bitte mache für deine Overpass API Probleme in JOSM einen neuen Faden auf. Hier geht es um Probleme mit der OSM API. Es macht keinen Sinn, hier beides zu diskutieren, da es völlig unterschiedliche Dienste sind.

In der Fehlermeldung steht oben zwar “Kommunikation mit dem OSM-Server fehlgeschlagen”. Weiter unten ist aber ein “osm3s_v…” request_read_and_idx::timeout. Das kommt also klar von Overpass API.

Eigentlich gibt es auch nicht wirklich viel zu diskutieren, Ovepass API ist im Moment überlastet wg. zu vielen Anfragen. Da spielt es auch keine Rolle, welche Version dein lokaler JOSM hat. Das Problem muss auf dem Server gelöst werden. → siehe https://wiki.openstreetmap.org/wiki/Overpass_API/status

Die Frage ist natürlich ob du Overpass bewusst in JOSM nutzen möchtest. Falls nicht, würde ich das für den Moment abstellen.
Das ist der Haken “Overpass-Server zum Herunterladen von Objekten benutzen” unter Einstellungen → OSM-Server.

Ich grätsch da mal auch noch mal rein, weil ich die api-probs nach wie vor mal sporadisch, mal nervig viel und mal gar nicht habe.
Mein Ticket wurde mit der Lösung sinngemäss: “Dein Problem” geschlossen. Hab bisschen meinen Traffic beobachtet und der sieht mindestens im Upload sehr gleichmässig (keine Lücken) aus.

Edit: mit Traffic meine ich gesamttraffic vom Rechner.
Edit2: Ja overpass-turbo&Co laggt tatsächlich derbe, ist aber hier tatsächlich nicht das Problem.

Es gibt übrigens ein Operations Issue dazu: https://github.com/openstreetmap/operations/issues/597

Die Probleme sind wahrscheinlich “outside of our control”. Da kann man wohl nichts machen.

Bei mir kommt dann auch die Fehlermeldung: Unexpected end of file from server

Ich kann mittlerweile ziemlich sicher sagen, dass das Problem nicht von meinem Rechner und nicht von meinem Netzwerk herkommt.

Ich hatte[1] das Problem diverse Male, sowohl an meinem Hauptrechner, als auch an meinem Reiserechner jeweils auf Handy-Hotspot. (Vorher sowohl am Kabel auf 100Mbit oder Wlan auf 10Mbit (jeweils DSL))

[1] Aktuell mappe ich sehr wenig, sodass ich das sehr selten zu Gesicht bekomme (kann auch Zufall sein…)

Hallo,

Auch ich bekomme immer wieder die beschriebene Meldung.

JOSM Revision:18427
JAVA 18.0.1.1
LINUX Manjaro

Ich erkennen keinerlei Zusammenhang hier mit “schnellem Absenden”; der Fehler wurde auch schon beim ersten Edit nach Programmstart gemeldet. Er tritt sporadisch auf, manche Tage gar nicht, anderer Tage mehrfach nacheinander (selbst bei einem Changeset). Ich erkenne keinen Einfluss, ob das Changeset eine oder viele Änderungen enthält.

Siehe Beitrag #29: https://forum.openstreetmap.org/viewtopic.php?pid=858235#p858235

Das Problem habe ich auch sporadisch seit Monaten. Es liegt weder an euch, noch an eurem Rechner, noch an eurem Netzwerk, es liegt wohl auch nicht am OSM-Server. Vielleicht liegt es an JOSM, an Java oder dem Internet zwischen uns und dem OSM-Server.
Mir scheint es hängt mit IPv4/IPv6 zusammen, meine Vermutung ist, dass das Problem nur auftritt, wenn das verwendete Netzwerk kein IPv6 kann. Wie sieht das bei euch aus?

Da der Fehler anscheinend nicht mit ID auftritt könnte es in der Tat an JOSM/Java liegen. :frowning:

Bei mir klappt das Hochladen nun teilweise erst beim 5ten Versuch. :frowning:

Hier ebenso; ich habe den Eindruck, dass die Häufigkeit und - bei Auftreten - die Anzahl der Abbrüche zunimmt.

Wieso ist der von mmd gelieferte Querverweis auf der verlinkten GitHub-Seite erledigt? Kann man das wieder aktivieren?

Nach Änderung der Java-Version scheint es bisher besser zu laufen. Mal schauen…

EDIT: Zu früh gefreut, auch mit Java 11 nun häufige Verbindungsfehler.

Mein Eindruck hier ist, dass es sich überwiegend um Probleme mit JOSM, genauer, mit diversen Java / JDK-Versionen handelt. Da macht es nicht wirklich viel Sinn, ein Operations-Ticket nochmal zu öffnen oder dort irgendwelche Kommentare zu posten. Das wird wg. Nicht-Reproduzierbarkeit gleich wieder geschlossen.

Mein Vorschlag wäre daher, konsequent Tickets für JOSM zu öffnen. Am besten macht ihr das direkt aus JOSM heraus auf, damit alle notwendigen Infos automatisch mit im Ticket übernommen werden. Möglicherweise helfen mehrere Tickets, das Problem besser einzugrenzen.

Wie schon früher erwähnt, bringt uns ein “Hochladen klappt nicht” hier im Forum keinen Schritt weiter, weil alle relevanten Infos zur Java-Version fehlen. Und ja, ein Forum ist kein Bugtracker und war dafür auch nie gedacht.

Danke! Ich habe Deinen Vorschlag

hier umgesetzt. Spricht etwas dagegen, dass weitere Nutzer dieses Ticket mit ihren individuellen StatusReports erweitern?

Wer hätte das gedacht, dass das Ticket den selben Weg geht wie meins: https://josm.openstreetmap.de/ticket/21806 :smiley:

Ich hab mal einen Kommentar dazu geschrieben, und wir haben das Thema noch etwas weiter diskutiert (daher auch der “Edit”) hier.

Das Hauptproblem ist, dass das ganze im Moment nicht einfach reproduzierbar ist, was aber notwendig wäre, um das ganze sinnvoll zu korrigieren. Zu der These, warum das mit JOSM häufiger auftritt als bspw. mit iD, gibt es die Idee, dass Browser in Fehlersituation eher mal schauen, ob man die Anfrage vielleicht doch nochmal gefahrlos auf die Reise schicken kann. JOSM gibt in solchen Situationen Fehlermeldungen eher mal an den User weiter, mit der Bitte, den Upload einfach erneut zu versuchen.

In den letzten Tagen habe ich das Problem auch wieder ein paar Mal gehabt. Da MichaelFS’ Ticket bereits geschlossen ist, bringt es etwas nochmal eins zu machen?
Sporadische Fehler sind natürlich immer schwierig, weil man sie nicht gezielt reproduzieren kann. Was könnte da helfen? Zusätzliches Logging einbauen oder mal Wireshark mitlaufen lassen bis zum Auftreten des Fehlers?

Hallo mmd,
vielen Dank für Deine fundierten Beiträge zu meinem JOSM-Ticket. Zur technischen Diskussion (WIRESHARK etc.) kann ich mangels Wissen nichts beitragen, aber der folgende Text von Dir ist mir aufgefallen:

Bei mir ist es definitiv so, dass der Fehler nur unmittelbar nach Start der UPload-Prozedur auftritt. Wenn ein Changeset mehrere Änderungen enthält, läuft der UPload immer durch, wenn die “Kontaktaufnahme” erfolgreich war.

Ich schreibe das hier, um den anderen Pfad nicht mit einem ggf. wenig sinnvollen Beitrag zu stören …

Hier genauso. CS-Grösse ist egal. (Kann mich auch nicht erinnern, dass mir mal was während dem upload abgeschmiert ist, es sei denn jmd. hat am Netzwerkkabel gezogen…)

Stimmt. Ich finde die Diskussion im JOSM-Ticket bewegt sich vom eigentlichen Problem weg.
Wie auch die Wireshark-Logs zeigen, bricht der Upload nicht in der Mitte ab, sondern schon der “Verbindungsaufbau” scheitert (siehe “connect”), bitte auch die Zeitstempel von Wireshark mit JOSM entsprechend abgleichen. Der Server schließt auf seiner Seite die Verbindung, aber JOSM oder Java scheinen darauf nicht richtig zu reagieren und der Neuaufbau der Verbindung schlägt fehl.
Es wäre schön, wenn zuerst dieses Problem behoben werden könnte. Natürlich wäre es auch gut, wenn mittendrin abgebrochene Uploads korrekt abgeschlossen werden könnten, aber das ist erstmal ein anderes Problem. Bei uns scheitert es ja schon vor dem Upload, wir kommen gar nicht bis zu einem möglichen Abbruch mittendrin, welcher bei mir übrigens auch noch noch nie vorgekommen ist.

Verwirrend ist noch, dass im Fehlerfall das Fenster “Befehlsstapel” gelöscht wird, obwohl gar nix hochgeladen wurde.