anchor.diff:  The value of `requests_per_second` can be changed on a running update by query
   using the `_rethrottle` API:
   
  -// provide API Example
  -[source,java]
  ---------------------------------------------------
  -
  ---------------------------------------------------
  -// CONSOLE
  -
  -The `task_id` can be found using the tasks API above.
  +[source,java]
  +--------------------------------------------------
  +RethrottleAction.INSTANCE.newRequestBuilder(client).setTaskId(taskId).setRequestsPerSecond(2.0f).get();
  +--------------------------------------------------
  +
  +The `taskId` can be found using the tasks API above.
   
   Just like when setting it on the `updateByQuery` API `requests_per_second`
  -can be either `unlimited` to disable throttling or any decimal number like `1.7`
  -or `12` to throttle to that level. Rethrottling that speeds up the query takes
  +can be either `Float.POSITIVE_INFINITY` to disable throttling or any positive
  +float to throttle to that level. Rethrottling that speeds up the query takes
   effect immediately but rethrotting that slows down the query will take effect
   on after completing the current batch. This prevents scroll timeouts.
  -
  -
  -[float]
  -[[picking-up-a-new-property]]
  -=== Pick up a new property
  -
  -Say you created an index without dynamic mapping, filled it with data, and then
  -added a mapping value to pick up more fields from the data:
  -
  -[source,java]
  ---------------------------------------------------
  -PUT test
  -{
  -  "mappings": {
  -    "test": {
  -      "dynamic": false,   <1>
  -      "properties": {
  -        "text": {"type": "text"}
  -      }
  -    }
  -  }
  -}
  -
  -POST test/test?refresh
  -{
  -  "text": "words words",
  -  "flag": "bar"
  -}
  -POST test/test?refresh
  -{
  -  "text": "words words",
  -  "flag": "foo"
  -}
  -PUT test/_mapping/test   <2>
  -{
  -  "properties": {
  -    "text": {"type": "text"},
  -    "flag": {"type": "text", "analyzer": "keyword"}
  -  }
  -}
  ---------------------------------------------------
  -// CONSOLE
  -
  -<1> This means that new fields won't be indexed, just stored in `_source`.
  -
  -<2> This updates the mapping to add the new `flag` field. To pick up the new
  -field you have to reindex all documents with it.
  -
  -Searching for the data won't find anything:
  -
  -// provide API Example
  -[source,java]
  ---------------------------------------------------
  -
  -{
  -  "query": {
  -    "match": {
  -      "flag": "foo"
  -    }
  -  }
  -}
  ---------------------------------------------------
  -// CONSOLE
  -// TEST[continued]
  -
  -[source,java]
  ---------------------------------------------------
  -{
  -  "hits" : {
  -    "total" : 0
  -  }
  -}
  ---------------------------------------------------
  -// TESTRESPONSE
  -
  -But you can issue an `updateByQuery` request to pick up the new mapping:
  -
  -// provide API Example
  -[source,java]
  ---------------------------------------------------
  -
  -{
  -  "query": {
  -    "match": {
  -      "flag": "foo"
  -    }
  -  }
  -}
  ---------------------------------------------------
  -// CONSOLE
  -// TEST[continued]
  -
  -[source,java]
  ---------------------------------------------------
  -{
  -  "hits" : {
  -    "total" : 1
  -  }
  -}
  ---------------------------------------------------
  -// TESTRESPONSE
  -
  -You can do the exact same thing when adding a field to a multifield.
  
positive.code: You can fetch the status of all running update-by-query requests with the
  <<tasks,Task API>>:
  
  // provide API Example
  
  [source,java]
  --------------------------------------------------
  
  --------------------------------------------------
  // CONSOLE
  
  The responses looks like:
  
  [source,java]
  --------------------------------------------------
  {
    "nodes" : {
      "r1A2WoRbTwKZ516z6NEs5A" : {
        "name" : "Tyrannus",
        "transport_address" : "127.0.0.1:9300",
        "host" : "127.0.0.1",
        "ip" : "127.0.0.1:9300",
        "attributes" : {
          "testattr" : "test",
          "portsfile" : "true"
        },
        "tasks" : {
          "r1A2WoRbTwKZ516z6NEs5A:36619" : {
            "node" : "r1A2WoRbTwKZ516z6NEs5A",
            "id" : 36619,
            "type" : "transport",
            "action" : "indices:data/write/update/byquery",
            "status" : {    <1>
              "total" : 6154,
              "updated" : 3500,
              "created" : 0,
              "deleted" : 0,
              "batches" : 4,
              "version_conflicts" : 0,
              "noops" : 0,
              "retries": {
                "bulk": 0,
                "search": 0
              }
              "throttled_millis": 0
            },
            "description" : ""
          }
        }
      }
    }
  }
  --------------------------------------------------
  
  <1> this object contains the actual status. It is just like the response json
  with the important addition of the `total` field. `total` is the total number
  of operations that the reindex expects to perform. You can estimate the
  progress by adding the `updated`, `created`, and `deleted` fields. The request
  will finish when their sum is equal to the `total` field.
  
  With the task id you can look up the task directly:
  
  // provide API Example
  [source,java]
  --------------------------------------------------
  
  --------------------------------------------------
  // CONSOLE
  // TEST[catch:missing]
  
  The advantage of this API is that it integrates with `wait_for_completion=false`
  to transparently return the status of completed tasks. If the task is completed
  and `wait_for_completion=false` was set on it them it'll come back with a
  `results` or an `error` field. The cost of this feature is the document that
  `wait_for_completion=false` creates at `.tasks/task/${taskId}`. It is up to
  you to delete that document.
  
  [float]
  [[docs-update-by-query-cancel-task-api]]
  
negative.code: It's also possible to do this whole thing on multiple indexes and multiple
  types at once, just like the search API:
  
  [source,java]
  --------------------------------------------------
  UpdateByQueryRequestBuilder updateByQuery = UpdateByQueryAction.INSTANCE.newRequestBuilder(client);
  
  updateByQuery.source("foo", "bar").source().setTypes("a", "b");
  
  BulkIndexByScrollResponse response = updateByQuery.get();
  --------------------------------------------------
  
  If you provide `routing` then the routing is copied to the scroll query,
  limiting the process to the shards that match that routing value:
  
  [source,java]
  --------------------------------------------------
  UpdateByQueryRequestBuilder updateByQuery = UpdateByQueryAction.INSTANCE.newRequestBuilder(client);
  
  updateByQuery.source().setRouting("cat");
  
  BulkIndexByScrollResponse response = updateByQuery.get();
  --------------------------------------------------
  
  `updateByQuery` can also use the <<ingest>> feature by
  specifying a `pipeline` like this:
  
  [source,java]
  --------------------------------------------------
  UpdateByQueryRequestBuilder updateByQuery = UpdateByQueryAction.INSTANCE.newRequestBuilder(client);
  
  updateByQuery.setPipeline("hurray");
  
  BulkIndexByScrollResponse response = updateByQuery.get();
  --------------------------------------------------
  
  [float]
  [[docs-update-by-query-task-api]]
  