OpenSearch/docs/reference/cluster/tasks.asciidoc
Jason Tedor 51d53791fe Remove lenient URL parameter parsing
Today when parsing a request, Elasticsearch silently ignores incorrect
(including parameters with typos) or unused parameters. This is bad as
it leads to requests having unintended behavior (e.g., if a user hits
the _analyze API and misspell the "tokenizer" then Elasticsearch will
just use the standard analyzer, completely against intentions).

This commit removes lenient URL parameter parsing. The strategy is
simple: when a request is handled and a parameter is touched, we mark it
as such. Before the request is actually executed, we check to ensure
that all parameters have been consumed. If there are remaining
parameters yet to be consumed, we fail the request with a list of the
unconsumed parameters. An exception has to be made for parameters that
format the response (as opposed to controlling the request); for this
case, handlers are able to provide a list of parameters that should be
excluded from tripping the unconsumed parameters check because those
parameters will be used in formatting the response.

Additionally, some inconsistencies between the parameters in the code
and in the docs are corrected.

Relates #20722
2016-10-04 12:45:29 -04:00

143 lines
4.6 KiB
Plaintext

[[tasks]]
== Task Management API
experimental[The Task Management API is new and should still be considered experimental. The API may change in ways that are not backwards compatible]
[float]
=== Current Tasks Information
The task management API allows to retrieve information about the tasks currently
executing on one or more nodes in the cluster.
[source,js]
--------------------------------------------------
GET _tasks <1>
GET _tasks?nodes=nodeId1,nodeId2 <2>
GET _tasks?nodes=nodeId1,nodeId2&actions=cluster:* <3>
--------------------------------------------------
// CONSOLE
<1> Retrieves all tasks currently running on all nodes in the cluster.
<2> Retrieves all tasks running on nodes `nodeId1` and `nodeId2`. See <<cluster-nodes>> for more info about how to select individual nodes.
<3> Retrieves all cluster-related tasks running on nodes `nodeId1` and `nodeId2`.
The result will look similar to the following:
[source,js]
--------------------------------------------------
{
"nodes" : {
"oTUltX4IQMOUUVeiohTt8A" : {
"name" : "H5dfFeA",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"tasks" : {
"oTUltX4IQMOUUVeiohTt8A:124" : {
"node" : "oTUltX4IQMOUUVeiohTt8A",
"id" : 124,
"type" : "direct",
"action" : "cluster:monitor/tasks/lists[n]",
"start_time_in_millis" : 1458585884904,
"running_time_in_nanos" : 47402,
"cancellable" : false,
"parent_task_id" : "oTUltX4IQMOUUVeiohTt8A:123"
},
"oTUltX4IQMOUUVeiohTt8A:123" : {
"node" : "oTUltX4IQMOUUVeiohTt8A",
"id" : 123,
"type" : "transport",
"action" : "cluster:monitor/tasks/lists",
"start_time_in_millis" : 1458585884904,
"running_time_in_nanos" : 236042,
"cancellable" : false
}
}
}
}
}
--------------------------------------------------
It is also possible to retrieve information for a particular task:
[source,js]
--------------------------------------------------
GET _tasks/task_id:1 <1>
--------------------------------------------------
// CONSOLE
// TEST[catch:missing]
<1> This will return a 404 if the task isn't found.
Or to retrieve all children of a particular task:
[source,js]
--------------------------------------------------
GET _tasks?parent_task_id=parentTaskId:1 <1>
--------------------------------------------------
// CONSOLE
<1> This won't return a 404 if the parent isn't found.
The task API can be also used to wait for completion of a particular task. The following call will
block for 10 seconds or until the task with id `oTUltX4IQMOUUVeiohTt8A:12345` is completed.
[source,js]
--------------------------------------------------
GET _tasks/oTUltX4IQMOUUVeiohTt8A:12345?wait_for_completion=true&timeout=10s
--------------------------------------------------
// CONSOLE
// TEST[catch:missing]
You can also wait for all tasks for certain action types to finish. This
command will wait for all `reindex` tasks to finish:
[source,js]
--------------------------------------------------
GET _tasks?actions=*reindex&wait_for_completion=true&timeout=10s
--------------------------------------------------
// CONSOLE
Tasks can be also listed using _cat version of the list tasks command, which accepts the same arguments
as the standard list tasks command.
[source,js]
--------------------------------------------------
GET _cat/tasks
--------------------------------------------------
// CONSOLE
[float]
=== Task Cancellation
If a long-running task supports cancellation, it can be cancelled by the following command:
[source,js]
--------------------------------------------------
POST _tasks/task_id:1/_cancel
--------------------------------------------------
// CONSOLE
The task cancellation command supports the same task selection parameters as the list tasks command, so multiple tasks
can be cancelled at the same time. For example, the following command will cancel all reindex tasks running on the
nodes `nodeId1` and `nodeId2`.
[source,js]
--------------------------------------------------
POST _tasks/_cancel?nodes=nodeId1,nodeId2&actions=*reindex
--------------------------------------------------
// CONSOLE
[float]
=== Task Grouping
The task lists returned by task API commands can be grouped either by nodes (default) or by parent tasks using the `group_by` parameter.
The following command will change the grouping to parent tasks:
[source,js]
--------------------------------------------------
GET _tasks?group_by=parents
--------------------------------------------------
// CONSOLE