Modify

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#2468 closed defect (duplicate)

JOSM upload failing - error 409

Reported by: mikh43 Owned by: team
Priority: blocker Milestone:
Component: Core Version: latest
Keywords: api6 upload 409 Cc: mikh43, Gubaer

Description

This is my second upload under API6 - the first worked - this one fails repeatedly with an error message that can only be read by failing the upload repeatedly! So far as I can see the server is returning error code 409 (java exception java.io.IOException). I have repeatedly tried downloading immediately before uploading and each time I get a single conflict with 'Park Road' (5 node way - id = 28422846). The conflict choices are deleted=true (mine) or =false (theirs). I have tried resolving either way. (If I accept deleted=false I am left with overlapping duplicate ways.) Neither choice allows me to upload. This is a fairly big changeset but not abnormal for a single GPS walk. I am using JOSM v 1555 and java version 1.0.6_13. I'm not doing any more editing until I know how to upload under API 6! I've spent a long time on this already.

Attachments (1)

conflict_value_empty.jpg (25.9 KB ) - added by anonymous 15 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 by DwiSecundus, 15 years ago

Cc: DwiSecundus added

comment:2 by westfa, 15 years ago

Hello,
I have had the same problem. I edited a .osm file with JOSM, newest developer version, and opened a second layer and did there a little thing. I uploaded this change, and it worked. But when I was finished with the big work, I could not upload it. And it was hard to see the error message, because the error message disappeared quickly. I would like to see improvements in this area (see ticket 2460 [1]). But to the actual bug:
I could not upload it, and with whireshark a friend of mine was able to find out what was going on: I deleted some nodes in the first changeset, but second changeset, which did not work, used this nodes. Of course this is a normal conflict, but why did JOSM not tell us about this? I even updated the data, but JOSM did not tell me a word about those conflicts. I think *that* is the actual error. Maybe josm does not recognize conflicts if
the changeset is really big.

I could solve the problem by spying the connection with wireshark (actually a friend of mine did that) see which nodes cause the conflict and delete the lines with the nodes and the ways by hand out of the .osm file. i could upload the new file without problems.

Hope this helps. :)

[1] http://josm.openstreetmap.de/ticket/2460

comment:3 by anonymous, 15 years ago

same problem for me. happens since api 0.6 with three different .osm files. error form the upload pop-up:

Übertragung wegen eines Fehlers abgebrochen (Wiederholung in 5 Sekunden):
java.io.IOException: Server returned HTTP response code: 409 for URL:
http://www.openstreetmap.org/api/0.6/changeset/976479/upload


this number changes for every trial

in fact there seems to be no retry, after 5 sec pop-up vanishes.

comment:4 by berndl, 15 years ago

missed to add my username and the following information in the previous update, sorry.

It seems that the upload does not fail completely, some of the tracks I added
made it into the database(as I can see they were rendered).
If it is helpful to get the .osm file let me know.

comment:5 by mikh43, 15 years ago

Further to my original ticket - the offending osm file still fails in the same way - from various experiments it does seem to have some connection with a deletion of a few nodes. If it is a JOSM problem then, as per westfa, it would be nice to get a chance to resolve - the normal procedure with conflict resolution doesn't help. Also - of course - the error message disappearing after 5 secs is nuts.
I have now made a completely new osm file (using josm) from the same original gpx data but only doing about half a dozen changes in each step - so far each small changeset uploads OK (including the one around the area that seemed to be causing the problem). Third time of processing this raw data (:<) once under api5 and abandoned after api upgrade, once giving an osm that won't upload and now building the newest osm a little at a time - tedious and presumably adding to server load with repeated download checks and uploads.
Are any of our gurus looking at this '409' problem?

comment:6 by mikh43, 15 years ago

Cc: mikh43 added

comment:7 by cyron@…, 15 years ago

Found the reason for this bug: JOSM does change the change itself, but it 'forget' to change the versionnumber. This was confirmed by another user and I think this is a very serious!

comment:8 by mikh43, 15 years ago

Good news - now that we know it is a bug and we know (thanks to cyron et al.) what is causing it I can at least relax and know that my installation is OK! I have just completed uploading the contents of the offending osm in very small chunks and (after three attempts!) can move onto the next gps trace. I'm not sure why reducing the size of the changeset helps but maybe it allows me to continue working while the clever JOSM folk sort out the bug - which is indeed a real blocker.

comment:9 by mikh43, 15 years ago

OK - I spoke too soon. Managed to get about ten changes into the second changeset on a completely new and different osm based on a new and different gpx - then struck down by the dreaded 409 again. Good night!

comment:10 by DwiSecundus, 15 years ago

Cc: DwiSecundus removed

comment:11 by Gubaer, 15 years ago

The defect can be reproduced with the following steps:

  • Start two JOSM instances JOSM_1 and JOSM_2
  • Download the same small dataset in JOSM_1 and in JOSM_2
  • In JOSM_1 create a node and set the tags
    amenity=biergarten
    testkey=testvalue1
    
  • In JOSM_1 upload the new node
  • In JOSM_2 select File -> Download from server. The new node is now also in JOSM_2
  • In JOSM_1 change the tags of the node to
    testkey=testvalue2
    

and upload

  • In JOSM_2 change the tags of the node to
    testkey=testvalue3
    
  • In JOSM_2 select File -> Upload to server. This will lead to
    POST http://api.openstreetmap.org/api/0.6/changeset/123456789/upload... Conflict
    

as expected.

  • In JOSM_2 select File -> Download from Server. This will lead to one merge conflict. There are two ways to resolve the conflict, either by selecting testkey=testvalue2 or testkey=testvalue3 neither of which resolves the conflict. Any subsequent upload in JOSM_2 will lead to
    POST http://api.openstreetmap.org/api/0.6/changeset/123456789/upload... Conflict
    

comment:12 by Gubaer, 15 years ago

Cc: Gubaer added

comment:13 by framm, 15 years ago

Resolution: fixed
Status: newclosed

Thank you for this thorough investigation! This bug was due to JOSM not properly transferring the confliciting object's version number in the process of conflict resolution. It should be fixed in r1561.

comment:14 by mikh43, 15 years ago

Resolution: fixed
Status: closedreopened

Thanks to Gubær, framm et al. for their hard work. I can see that what Gubær did is a good simulation of what I was doing each time I hit 409. When will the bug fix be included in josm-latest.jar? Or is this something I can patch myself? If so, could someone give me idiot-proof step-by-step instructions as I am not a java programmer and don't even know the location of the code or the meaning of 'trunk' - sorry guys - my programming is far too out-of-date to handle new-fangled things like java script (but if you want machine language programming for an IBM 360 mainframe pr assembler for a PDP-9 ..... (;>)). Call me the ancient mariner ('stoppeth one of three' - rather like my performance at ball games these days).

comment:15 by mikh43, 15 years ago

Resolution: fixed
Status: reopenedclosed

Apologies - I see that it is there in v1561 ... many, many thanks ... now back to mapping when my meetings are done ...

comment:16 by cyron@…, 15 years ago

Resolution: fixed
Status: closedreopened

still isn't really fixed, I got an .osm with some changes which are still not in the database, I refreshed all data via menupoint, fixed all conflicts, uploading and got "provided version 1 server had version 2 of node".

I will retry, maybe someone only edited something but I think the problem is still there.

comment:17 by cyron@…, 15 years ago

Okay, testing the thing to reproduce, leading to that the node still isnt updated and no conflict is detected.

comment:18 by mikh43, 15 years ago

Same here - I am no longer getting 5-second flash-past-your-eyes 409 messages but am receiving messages of the type "provided version x server had version y of node" and a bunch of conflicts to resolve. As long as I resolve in favour of "theirs" and not "mine" I seem to be able to get rid of the conflicts and can then go in and re-edit (but sometimes have to completely delete a way or the problem recurs). But this is slightly less of a blocker as I seem able to get at least some of the data uploaded.

by anonymous, 15 years ago

Attachment: conflict_value_empty.jpg added

comment:19 by berndl, 15 years ago

I tried version 1561 and essentially got same problems as described above.
Did the following with an .osm file containing only a few nodes and ways:

  • update to server, got "Version mismatch: Provided 4, server had: 5 of Way 23150509"
  • reloaded the region from server, got "Konflikte beim Importieren aufgetreten" in english: "conflicts during import"
  • tried to resolve conflicts, this seems to be impossible because 'my value' and 'their value' is empty (see screenshot: conflict_value_empty.jpg)

This left me stuck in a loop and I decided to discard my .osm file because redrawing
takes less time then to try workarounds for this bug.

comment:20 by Gubaer, 15 years ago

There are still cases cases where JOSM doesn't detect and/or resolve conflicts correctly. One of them is related to merging primitive versions which are semantically equal but differ in their version number. See #2507 for a description and a patch.

in reply to:  20 comment:21 by Gubaer, 15 years ago

Replying to Gubaer:

There are still cases cases where JOSM doesn't detect and/or resolve conflicts correctly. One of them is related to merging primitive versions which are semantically equal but differ in their version number. See #2507 for a description and a patch.

... and #2510 for another case

comment:22 by stoecker, 15 years ago

Resolution: duplicate
Status: reopenedclosed

comment:23 by stoecker, 15 years ago

Closed as duplicate of #2609.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.