You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Filipe Manana (Commented) (JIRA)" <ji...@apache.org> on 2011/11/16 12:16:51 UTC

[jira] [Commented] (COUCHDB-1341) calculate replication id using only db name in remote case

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

Filipe Manana commented on COUCHDB-1341:
----------------------------------------

Hi Bob, that's definitely an issue.

However I think that are 2 issues by using this approach of considering only the remote db name and excluding the server/port component of the URL.

Imagine that on a CouchDB instance you trigger these 2 replications:

(replication 1)
{
    "source": "http://server1.com/foo",
    "target": "bar"
}

(replication 2)
{
    "source": "http://server2.com/foo",
    "target": "bar"
}

>From what I understand, both will have the same replication ID with this patch, right?
If so you can't have both replications running in parallel, one of them will have conflict error when updating its checkpoint local doc (because it's the same for both).

Also, if you start replication 1, followed by replication 2 and then followed by replication 1 again, we can lose the benefits of the checkpointing.
Suppose you start replication 1, after it finishes the checkpoint document's most recent history entry has source sequence 1 000 000.
Then you start replication 2. Because the ID is the same as replication 1, it will overwrite the checkpoint document. If it checkpoints more than 50 times (the maximum history length), all checkpoint entries from replication 1 are gone. When it finishes, if you start replication 1 again, it will no longer find entries in the checkpoint history related to it, so the replication will start from sequence 0 instead of 1 000 000.

Basically, if we have a source or target like "http://user:password@server.com/dbname", I think we should consider everything from the URL except the password (eventually the protocol as well).
                
> calculate replication id using only db name in remote case
> ----------------------------------------------------------
>
>                 Key: COUCHDB-1341
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1341
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Replication
>            Reporter: Bob Dionne
>            Assignee: Bob Dionne
>            Priority: Minor
>
> currently if the source or target in a replication spec contains user/pwd information it gets encoded in the id which can cause restarts if the password changes. Change it to use just the db name as the local case does, Here's a draft[1] of a solution.
> [1] https://github.com/bdionne/couchdb/compare/master...9767-fix-repl-id

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira