Api Probleme

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.

Stimmt, es würde mehr Sinn machen, zunächst das Erzeugen oder der Update des Changesets zu fixen. Ich habe übrigens genau dieses Thema schon in das Operations-Issue übernommen: https://github.com/openstreetmap/operations/issues/597#issuecomment-1164317177

Mir ist noch nicht klar, ob das Problem nun rein mit der Rails-Seite, oder nur der JOSM-Seite, oder auch einer Kombination von beiden zusammenhängt.

Heute läufts bis jetzt gut. Kann es sein, dass das ganze einfach ein Lastproblem auf Server-Seite ist?

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?