couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Date Mon, 05 Nov 2012 20:24:13 GMT


Robert Newson commented on COUCHDB-1259:

Jens, Yes, the patch goes further than the ticket, I said as much in my first comment when
I took the ticket. As you note, it has no security implications.

There are three host:port values in play for any one replication task, it seems only a partial
solution to fix the stability issue for one of them (though, I agree, that if we only fixed
one, it would be the co-ordinating node).

It is true that the host:port of the co-ordinating node does not affect the replication per
se, as long as you ignore what would go wrong if two processes were doing the same replication.
This is also true of the host:port of the "source" and "target" servers too.

I am happy to solve just the initial problem identified in the ticket if that will allow Benoit
to retract his veto, however I felt it important that we were all clear about the security
implications here (namely, that there are none) before proceeding. If, as seems the case now,
we all agree on the security aspect, I don't see the harm in all 3 participants having a stable
identifier allowing replication checkpoints to be used if a machine changes name or port.
> Replication ID is not stable if local server has a dynamic port number
> ----------------------------------------------------------------------
>                 Key: COUCHDB-1259
>                 URL:
>             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:

View raw message