couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Smith (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Date Wed, 24 Aug 2011 03:47:31 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089982#comment-13089982
] 

Jason Smith commented on COUCHDB-1259:
--------------------------------------

@Paul, I overlooked or misunderstood Randal's point about duplicating the UUID. Makes sense.

@Paul and Jens, totally: URLs are unstable. And, in general, on the web, if a URL changes,
that is a huge piece of information. That is a huge hint that you need to re-evaluate your
assumptions. Exhibit A: the replicator starts from scratch if you give it a new URL. That
is the correct general solution.

Your requirement to change the couch URL and everything is just fine and the application doesn't
have to worry--I think that requirement is asking CouchDB to be a bad web citizen. In other
words, IMO you have an application-level problem, not a couch problem, *except* that even
if you could determine everything is alright, you can't specify the replication ID.

I think Damien just time-traveled again.

BTW, @Jens, you can already give Apache CouchDB a UUID for your own needs. If you have admin
access, just put it anywhere, /_config/jens/uuid. If an unprivileged client must know this
UUID, then change the "Welcome" mesage in _config/httpd_global_handlers/%2f. Any unprivileged
client can find it there. (You could also place the UUID in the authentication realm in _config/httpd/WWW-Authenticate
which actually sounds sort of appropriate.) Finally, if you are willing to run a fork (which
mobile Couchbase is) then you could add any feature you need which doesn't make sense for
Apache CouchDB.

> 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
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message