Modify

Opened 13 years ago

Last modified 12 months ago

#6151 new defect

If upload ends with internal server error, no warning is shown

Reported by: bilbo Owned by: team
Priority: critical Milestone:
Component: Core Version: tested
Keywords: Cc:

Description (last modified by verdy_p)

I was using upload of larger amount of elements, with uploading by parts.

I found out, that if upload ends with internal server error, then no error message is shown and there is no indication that upload went wrong (except that if you opress "upload" again, you get upload dialog (with objects remaining to be uploaded) instead of "Nothing to upload")

In such cases (Internal server error received from server), the upload should either autmatically resume, or at least warn user that something went wrong (like a messagebox), instead of silently terminating the upload (so user thinks everything was uploaded OK).

Only this message is shown on JOSM console:

POST http://www.openstreetmap.org/api/0.6/changeset/7675004/upload... Internal Server Error
Waiting 10 seconds ... org.openstreetmap.josm.io.OsmTransferCancelledException
        at org.openstreetmap.josm.io.OsmApi.sleepAndListen(OsmApi.java:455)
        at org.openstreetmap.josm.io.OsmApi.sendRequest(OsmApi.java:540)
        at org.openstreetmap.josm.io.OsmApi.sendRequest(OsmApi.java:479)
        at org.openstreetmap.josm.io.OsmApi.uploadDiff(OsmApi.java:429)
        at org.openstreetmap.josm.io.OsmServerWriter.uploadChangesInChunks(OsmServerWriter.java:163)
        at org.openstreetmap.josm.io.OsmServerWriter.uploadOsm(OsmServerWriter.java:205)
        at org.openstreetmap.josm.gui.io.UploadPrimitivesTask.realRun(UploadPrimitivesTask.java:236)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:83)
        at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:129)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)

Attachments (0)

Change History (7)

comment:1 by skyper, 13 years ago

Priority: normalcritical

This can lead to many duplicated objects (errors).

in reply to:  1 comment:2 by bilbo, 13 years ago

Replying to skyper:

This can lead to many duplicated objects (errors).

Probably not, in this case there is greater chance of user mistakenly assuming that everything is uploaded well - which could be even worse, since some data that are expected to be on server would be missing then.

As for duplicated uploads, it is quite common problem. I think this could be remedied by setting some reasonable default to uploading to changeset (like setting "upload data in chunks of size 500" instead of "all at once"). This would lessen chance for timeouts (server should process 500 objects in much less time than several thousands) and impact of duplicates if timeouts happen (you get 500 extra objects in such case instead of several thousands)

comment:3 by brycenesbitt, 13 years ago

++ on this. I've seen it also.

comment:4 by verdy_p, 11 years ago

Description: modified (diff)

++ I still experience some long uploads that I leave finishing in the background, and that terminate without notice. I only note that it was not fished when I continue editing and submit new unrelated data which get mixed in the same changeset instead of being separated. This adds confusion when reviewing changes as nothing indicates that some new objects may be duplicated later.

comment:5 by bastiK, 9 years ago

Is there a good way to trigger an internal server error? Otherwise this is hard to test.

in reply to:  5 comment:6 by Don-vip, 9 years ago

Replying to bastiK:

Is there a good way to trigger an internal server error?

Only ways I know are:
https://trac.openstreetmap.org/ticket/4692
https://trac.openstreetmap.org/ticket/5249

comment:7 by mmd, 12 months ago

Since the underlying implementation for the changeset upload (and many other parts of the API as well) has moved from Rails to CGImap back in 2019, the issues mentioned in the referenced trac tickets should no longer be relevant today.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to bilbo.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


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