Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Wed, 7 Sep 2011 18:43:09 +0000 (UTC)
From: "Filipe Manana (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <1379381595.26906.1315420989993.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <709518339.19230.1315292473276.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (COUCHDB-1271) Impossible to cancel replications
 in some scenarios
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Filipe Manana commented on COUCHDB-1271:
----------------------------------------

Robert, if one clause doesn't need the user context, I think it's simpler to not receive it. As for the different calls, they're necessary, as when the user  specifies an id an additional step must be done (checking of permission).
Thanks for the opinion.

> Impossible to cancel replications in some scenarios
> ---------------------------------------------------
>
>                 Key: COUCHDB-1271
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1271
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>            Reporter: Filipe Manana
>            Assignee: Filipe Manana
>             Fix For: 1.2
>
>
> In some scenarios it's impossible to cancel a replication by posting to /_replicate, namely:
> 1) A filtered replication is started, the filter's code is updated in the source database, therefore's a subsequent cancel request will not generate the old replication ID anymore, has it got a different filter code;
> 2) Dynamically changing the httpd port will also result in the impossibility of computing the right replication ID
> Finally, it's also nicer for users to not need to remember the exact replication object posted before to /_replicate.
> The new approach, in addition to the current approach, allows something as simple as:
> POST /_replicate
> {"replication_id": "0a81b645497e6270611ec3419767a584+continuous+create_target",  "cancel": true}
> The replication ID can be obtained from a continuous replication request's response (field "_local_id"), _active_tasks (field "replication_id") or from the log.
> Aliases "_local_id" and "id" are allowed instead of "replication_id".
> Patch:
> https://github.com/fdmanana/couchdb/commit/c8909ea9dbcbc1f52c5c0f87e1a95102a3edfa9f.diff
> (depends on COUCHDB-1266)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira