Potlatch sometimes uploads duplicates ways (and presumably nodes/relations) after API 0.6 when creating new objects #2374
Comments
|
Author: tom[at]compton.nu I'm not convinced this is going to be down to timeouts - potlatch edits are normally small so don't take long to apply. |
|
Author: Richard IME the "operation completed but no response received from server" scenario is most common when updating large objects, typically long route relations. If it happens with a small object, it's usually the result of a connection failure somewhere between Potlatch (the SWF) and OSM. Potlatch doesn't give the id 0 to new objects. It gives unique negative ids as about five seconds' use should tell you. :) Otherwise, how would it cope with a closed way, where the same node occurs twice? Per-changeset storage would be one way of storing this but I'm not aware of any way of doing that, other than something really hacky like serialising into (presumably a set of) temporary tags that are deleted on changeset close. As a point of order, on point 3, Potlatch doesn't try again unless you expressly tell it to. I think the real answer is to boot t@h et al off the server and use it for editors only. ;) |
|
Author: Richard I've committed a change to amf_controller that now streams the response to all AMF calls as they're done, rather than assembling the responses into a big array and sending once all the calls are done. If you open up Activity Monitor in Safari, or whatever your browser's equivalent is, you can see the data start to stream through. (So Potlatch now has the only streaming part of the API. ;) ) One of the advantages of this is that the six-byte response header is written immediately by amf_controller... acting like an initial Keep-Alive, almost. So I'd be interested to see whether this might help to address the "operation completed but no response received from server" issue. |
|
Author: iandees Cleaning aging tickets. |
Reporter: avarab[at]gmail.com
[Submitted to the original trac issue database at 4.19pm, Wednesday, 14th October 2009]
(This has more to do with amf_controller.rb than Potlatch proper so putting it in the website component)
See e.g.:
(deleted now)
Presumably this happens like this:
Perhaps this could be worked around like this:
Or on the client/server side:
I'm not sure but it looks like Potlatch gives the ID "0" to all new objects. Perhaps if it gave unique negative IDs to all objects those IDs could be tracked on a per-changeset basis on the server side. If an ID comes up again from the client indicate that he's submitting a duplicate.
The text was updated successfully, but these errors were encountered: