Replication ID is not stable if local server has a dynamic port number
----------------------------------------------------------------------
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
I noticed that when Couchbase Mobile running on iOS replicates to/from a remote
server (on iriscouch in this case), the replication has to fetch the full
_changes feed every time it starts. Filipe helped me track down the problem --
the replication ID is coming out different every time. The reason for this is
that the local port number, which is one of the inputs to the hash that
generates the replication ID, is randomly assigned by the OS. (I.e. it uses a
port number of 0 when opening its listener socket.) This is because there could
be multiple apps using Couchbase Mobile running on the same device and we can't
have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a unique ID
for a particular pair of {source, destination} databases, but it's basing it on
attributes that aren't fundamental to the database and can change, like the
hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or each
server?) a random UUID when it's created, and use that to generate replication
IDs.
Another solution, proposed by Damien, is to have CouchDB let the client work
out the replication ID on its own, and set it as a property in the replication
document (or the JSON body of a _replicate request.) This is even more flexible
and will handle tricky scenarios like full P2P replication where there may be
no low-level way to uniquely identify the remote database being synced with.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
