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 (JIRA)" <ji...@apache.org> on 2011/09/06 09:01:13 UTC
[jira] [Created] (COUCHDB-1271) Impossible to cancel replications
in some scenarios
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
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
[jira] [Commented] (COUCHDB-1271) Impossible to cancel replications
in some scenarios
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097806#comment-13097806 ]
Robert Newson commented on COUCHDB-1271:
----------------------------------------
I like the API. I added the original "cancel":true feature and agree that it has all of the above holes.
Could the two cancel_replication functions become two clauses of a single function (where user_ctx is nil in the one case)? I think that would be a little clearer since you could call cancel_replication just once in replicate/1.
> 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
[jira] [Commented] (COUCHDB-1271) Impossible to cancel replications
in some scenarios
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (COUCHDB-1271) Impossible to cancel replications
in some scenarios
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana resolved COUCHDB-1271.
------------------------------------
Resolution: Fixed
Applied to trunk and branch 1.2.x
> 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
[jira] [Assigned] (COUCHDB-1271) Impossible to cancel replications
in some scenarios
Posted by "Filipe Manana (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Filipe Manana reassigned COUCHDB-1271:
--------------------------------------
Assignee: Filipe Manana
> 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