Error "Document element should be osmChange" on upload

[mdk]

I'm using JOSM 4667/de on WinXP.

The last two changesets raise an error at the end of the upload:

Der OSM-Server "​http://api.openstreetmap.org/api/0.6/" meldet fehlerhafte Anfrage.
Fehlermeldung (englisch): Document element should be 'osmChange'.

The changeset is not closed, but all objects are uploaded. The command list still show all changes.

On my other computer I use 4667/en under Ubuntu and I have no problems!

[bastiK]

Could be a network or server error. Do you get this message for each upload? If so, can you check what JOSM sends to the server (e.g. with wireshark)?

[mdk]

It's hard to find a pattern. But it looks like:

• Changesets with a few changes (50 objects)have no problems
• Changesets with a lot of changes (>1000 objects) cause the problems (but only on Windows. With Ubuntu I uploaded changesets with 16000 and 22000 object without problems)
• On windows I saw in the problematic uploads, that the was a message like "try 1 of 5" then there was a countdown then "2 of 5" and so on. On Ubuntu I never get this messages.
• When I break down the upload in small packages, I also have no problems. But because of worse problems with conflicts, I hat to use the package size=1, which takes too much time to upload large changesets. So I changed the configuration back to one package (which is absolutly no problem with much bigger changesets in Ubuntu!)

It looks like JOSM has problems to keep the connection to the server when running under Windows. From my own programming expiriences I know, that Windows has a global defined timeout for closing sockets, if they are idle for some time (TcpTimedWaitDelay). This Value is normally 240 Sec.

Because we run out of Sockets in a project, I remember, that I reduced the value as describt here: ​https://www-304.ibm.com/support/docview.wss?uid=swg21267490

I'm not shure, if I revert this change, because HKEY_LOCAL_MACHINE\System\CurrectControlSet\services\Tcpip\Parameters\TcpTimedWaitDelay is not set (=default), but on Windows there are always many different ways to do the same thing :-/

Perhaps JOSM need to send explicitly some keepalive messages to server?

[bastiK]

Replying to mdk:

Perhaps JOSM need to send explicitly some keepalive messages to server?

Would that help when Windows closes the connection? If you are able to fix JOSM yourself, please submit the patch. I'll close this for now because it might be caused by your special configuration.

[Luebeck]

i have the same problem by josm 4857 win7. parts of the current osm-changes will be update.

now i reinstall 4765 and then i can upload my changes. some conflicts must be fixed - but the data's are online!

(sorry for the other posting - miswork of browser)