Benoit This problem has nothing to do with any application, its a bug in CouchDB with a simple fix
On 4 November 2012 20:43, Benoit Chesneau (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490449#comment-13490449] > > Benoit Chesneau commented on COUCHDB-1259: > ------------------------------------------ > > Hello.... are you understanding that this isn't only about your > application? Some may have different uses. And different routing policy. > And this is not the role of couchdb to fix them. > > > 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 >
