Ticket #2374 (closed defect: fixed)

Opened 5 years ago

Last modified 7 months ago

Potlatch sometimes uploads duplicates ways (and presumably nodes/relations) after API 0.6 when creating new objects

Reported by: avarab@… Owned by: richard@…
Priority: major Milestone:
Component: potlatch (flash editor) Version:
Keywords: ban_avar Cc:

Description

(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:

  1. Potlatch saves a new way (or node/relation) to the server
  2. The server accepts it & writes it to the data but times out, doesn't reply
  3. Potlatch gets tired of waiting/doesn't get a reply. Tries again
  4. A duplicate way is created

Perhaps this could be worked around like this:

  1. If Potlatch tries to save an object but isn't successful add it to a list of suspect objects on the client-side
  2. Poll the server to see if those objects were really created
  3. If not, save again

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.

Change History

comment:1 Changed 5 years ago by tom@…

  • Owner changed from tom@… to richard@…
  • Component changed from website to potlatch (flash editor)

I'm not convinced this is going to be down to timeouts - potlatch edits are normally small so don't take long to apply.

comment:2 Changed 5 years ago by Richard

  • Keywords ban_avar added; ban_potlatch removed

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

comment:3 Changed 4 years ago by 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.

comment:4 Changed 7 months ago by iandees

  • Status changed from new to closed
  • Resolution set to fixed

Cleaning aging tickets.

Note: See TracTickets for help on using tickets.