[OSM-dev] [OSM-talk] Is there some lag in the backend data?

[Paul Norman]

> From: Stephan Knauss [mailto:osm at stephans-server.de]
> Sent: Tuesday, July 23, 2013 5:30 AM
> Cc: talk at openstreetmap.org
> Subject: Re: [OSM-talk] Is there some lag in the backend data?
> 
> For me this sounds more like a replication problem. Data is available
> immediately. It's not related to closing a changeset.
> 
> Is the API delivering /map call responses from the main database or from
> a read-only replication?

The main API is either from the main database or from a database set up 
with postgresql replication where the latency is measured in milliseconds.

> If its the later than JOSM might need to be extended to evaluate a
> timestamp to detect outdated responses.

Although this talk@ message isn't relevant for JOSM accessing the main 
API as it currently exists, it made me think.

My GSOC project is a service a mirror that uses replication *and* you can 
use as a replacement for the main API in your client. E.g. with JOSM you 
can change the API URL in it and have everything work seamlessly.

What this talk@ message got me wondering is what if anything needs changing 
in an editor to account for replication lag. Due to the nature of
replication 
there can be a 0-5 minute delay in information getting into the replicated 
database. A good server can average about 45 seconds and streaming
replication
has the potential to bring this down to under 15 seconds.

This does not make conflicts with other users worse. The time required for 
download, editing and upload is long enough in comparison to replication lag
that you won't have a significant increase in conflicts.

Where it might run into problems is if there is a scenario where a user
uploads
changes and then immediately requests the latest version from the API. In
this 
scenario my service would of transparently proxied the main API for the
upload
then answered from its own data to the latest version request. The reply for
the
upload and the reply to the latest version request would then be
inconsistent.

On the other hand, I can't see when a client would actually do this.

Is anyone aware of any clients where this scenario can come up, or of other 
scenarios where different API calls having different delays could matter?