[ https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490441#comment-13490441 ]
Jens Alfke commented on COUCHDB-1259: ------------------------------------- > 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. *sigh* No, that is exactly the situation I was describing. The mobile client is the only one initiating replication; it pulls from the central (fixed-address) server, and pushes changes to it. So the mobile device's IP address and port are irrelevant, right? Except that the replication state document stored in _local has an ID based on several things _including_ the local server's address and port number. So the effect is that, every time the app launches, all the replication state gets lost/invalidated, and it has to start over again the next time it replicates. TouchDB doesn't have this problem because I didn't write it with this design flaw :) Instead every local database has a UUID as suggested here, and that's used as part of the key. > 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