Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.210.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1132244544.68136.1352107512357.JavaMail.jiratomcat@arcas>
References: 
 <1220942000.7101.1314138329138.JavaMail.tomcat@hel.zones.apache.org>
	<1132244544.68136.1352107512357.JavaMail.jiratomcat@arcas>
Date: Mon, 5 Nov 2012 10:27:24 +0100
Message-ID: 
 <CAJNb-9rABwQV1ns+zvT7Q4Gf4KeZPM90cGgCDnsXrSMNd_QWsw@mail.gmail.com>
Subject: Re: [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if
 local server has a dynamic port number
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=e89a8f3baf03debd8404cdbc1774

--e89a8f3baf03debd8404cdbc1774
Content-Type: text/plain; charset=ISO-8859-1

On Nov 5, 2012 10:25 AM, "Robert Newson (JIRA)" <jira@apache.org> wrote:
>
>
>     [
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490527#comment-13490527]
>
> Robert Newson commented on COUCHDB-1259:
> ----------------------------------------
>
> Benoit, are you vetoing this change? If so, please include a reason why
improving the hit rate for replication checkpoints should not be included
in our next release.

how does it improve the hit rate? how is it related to this ticket?
>
> Everyone else, please comment on the patch itself, I want feedback on 1)
the quality and correctness of the patch and 2) whether, when using UUID,
whether it is correct to use UUID instead of the {Scheme, UserInfo, UUID,
Path} tuple that I've chosen as I would prefer to simply use the UUID if
it's correct to do so for clarity.
>
> https://github.com/apache/couchdb/pull/35
>
>
> > 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

--e89a8f3baf03debd8404cdbc1774--