Api Probleme

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?

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