Uploaded image for project: 'CouchDB'
  1. CouchDB
  2. COUCHDB-1271

Impossible to cancel replications in some scenarios

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 1.2
    • Replication
    • None

    Description

      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)

      Attachments

        Activity

          People

            fdmanana Filipe David Borba Manana
            fdmanana Filipe David Borba Manana
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: