[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490433#comment-13490433
]
Benoit Chesneau commented on COUCHDB-1259:
------------------------------------------
We don't speak about different things. We are expecting different behaviours
however.
If you have a dynamic port assignment then how knows the other node the new
port ? There are no other way than a ping-pong here. Ping-Pong that can be done
in different manner. To know this new port you will have to update the
replicator doc. Or the replication client could check on an adress table etc...
In any case there will be a dialog that can be different across applications.
And this is the point, this part is generally the logic of the application or
the routing policy. A server id can be use as an adress point but some could
decide to use other parameters to associate this replication id to a node.
Maybe instead of relying on a fixed node id, we could however introduce an
arbitrary remote id. This remote ID would be associated by default to an host
, port. The layer assigning this address id to the host/port could be
switchable, so the application or user could introduce easily its own routing
policy. Which could be relying on a server id ? Eventually if there is an
interrest like we do for the auth handlers or uuid generators, we could have
different implementations shipped with couchdb. One for example relying on a
server id.
btw your example with couchbase mobile is generally solved by using the
replication in pull mode only. So here it is relying on a fixed address to
replicate. A central node is then used as a meeting point for all the data
coming from other nodes and the replication is filtered per nodes.
> 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
> Assignee: Robert Newson
> Priority: Blocker
> Fix For: 1.3
>
> Attachments: couchdb-1259.patch, couchdb-1259.patch
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
