2020-03-20 09:04:33 -04:00
|
|
|
[role="xpack"]
|
|
|
|
[testenv="basic"]
|
|
|
|
[[async-search]]
|
|
|
|
=== Async search
|
|
|
|
|
|
|
|
The async search API let you asynchronously execute a
|
|
|
|
search request, monitor its progress, and retrieve partial results
|
|
|
|
as they become available.
|
|
|
|
|
|
|
|
[[submit-async-search]]
|
|
|
|
==== Submit async search API
|
|
|
|
|
|
|
|
Executes a search request asynchronously. It accepts the same
|
|
|
|
parameters and request body as the <<search-search,search API>>.
|
|
|
|
|
|
|
|
[source,console,id=submit-async-search-date-histogram-example]
|
|
|
|
--------------------------------------------------
|
|
|
|
POST /sales*/_async_search?size=0
|
|
|
|
{
|
2020-07-21 15:49:58 -04:00
|
|
|
"sort": [
|
|
|
|
{ "date": { "order": "asc" } }
|
|
|
|
],
|
|
|
|
"aggs": {
|
|
|
|
"sale_date": {
|
|
|
|
"date_histogram": {
|
|
|
|
"field": "date",
|
|
|
|
"calendar_interval": "1d"
|
|
|
|
}
|
2020-03-20 09:04:33 -04:00
|
|
|
}
|
2020-07-21 15:49:58 -04:00
|
|
|
}
|
2020-03-20 09:04:33 -04:00
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[setup:sales]
|
2020-03-26 04:40:05 -04:00
|
|
|
// TEST[s/size=0/size=0&wait_for_completion_timeout=10s&keep_on_completion=true/]
|
2020-03-20 09:04:33 -04:00
|
|
|
|
|
|
|
The response contains an identifier of the search being executed.
|
|
|
|
You can use this ID to later retrieve the search's final results.
|
|
|
|
The currently available search
|
|
|
|
results are returned as part of the <<search-api-response-body,`response`>> object.
|
|
|
|
|
|
|
|
[source,console-result]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
|
|
|
"id" : "FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=", <1>
|
|
|
|
"is_partial" : true, <2>
|
|
|
|
"is_running" : true, <3>
|
|
|
|
"start_time_in_millis" : 1583945890986,
|
|
|
|
"expiration_time_in_millis" : 1584377890986,
|
|
|
|
"response" : {
|
|
|
|
"took" : 1122,
|
|
|
|
"timed_out" : false,
|
|
|
|
"num_reduce_phases" : 0,
|
|
|
|
"_shards" : {
|
|
|
|
"total" : 562, <4>
|
|
|
|
"successful" : 3, <5>
|
|
|
|
"skipped" : 0,
|
|
|
|
"failed" : 0
|
|
|
|
},
|
|
|
|
"hits" : {
|
|
|
|
"total" : {
|
|
|
|
"value" : 157483, <6>
|
|
|
|
"relation" : "gte"
|
|
|
|
},
|
|
|
|
"max_score" : null,
|
|
|
|
"hits" : [ ]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
// TESTRESPONSE[s/FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=/$body.id/]
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
// TESTRESPONSE[s/"is_partial" : true/"is_partial": $body.is_partial/]
|
|
|
|
// TESTRESPONSE[s/"is_running" : true/"is_running": $body.is_running/]
|
2020-03-20 09:04:33 -04:00
|
|
|
// TESTRESPONSE[s/1583945890986/$body.start_time_in_millis/]
|
|
|
|
// TESTRESPONSE[s/1584377890986/$body.expiration_time_in_millis/]
|
|
|
|
// TESTRESPONSE[s/"took" : 1122/"took": $body.response.took/]
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
// TESTRESPONSE[s/"num_reduce_phases" : 0,//]
|
2020-03-20 09:04:33 -04:00
|
|
|
// TESTRESPONSE[s/"total" : 562/"total": $body.response._shards.total/]
|
|
|
|
// TESTRESPONSE[s/"successful" : 3/"successful": $body.response._shards.successful/]
|
|
|
|
// TESTRESPONSE[s/"value" : 157483/"value": $body.response.hits.total.value/]
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
// TESTRESPONSE[s/"relation" : "gte"/"relation": $body.response.hits.total.relation/]
|
|
|
|
// TESTRESPONSE[s/"hits" : \[ \]\n\s\s\s\s\}/"hits" : \[\]},"aggregations": $body.response.aggregations/]
|
2020-03-20 09:04:33 -04:00
|
|
|
|
2020-04-29 09:21:26 -04:00
|
|
|
<1> Identifier of the async search that can be used to monitor its progress,
|
|
|
|
retrieve its results, and/or delete it
|
|
|
|
<2> When the query is no longer running, indicates whether the search failed
|
|
|
|
or was successfully completed on all shards. While the query is being
|
|
|
|
executed, `is_partial` is always set to `true`
|
2020-03-20 09:04:33 -04:00
|
|
|
<3> Whether the search is still being executed or it has completed
|
|
|
|
<4> How many shards the search will be executed on, overall
|
|
|
|
<5> How many shards have successfully completed the search
|
2020-04-29 09:21:26 -04:00
|
|
|
<6> How many documents are currently matching the query, which belong to the
|
|
|
|
shards that have already completed the search
|
|
|
|
|
|
|
|
NOTE: Although the query is no longer running, hence `is_running` is set to
|
|
|
|
`false`, results may be partial. That happens in case the search failed after
|
|
|
|
some shards returned their results, or when the node that is coordinating the
|
|
|
|
async search dies.
|
2020-03-20 09:04:33 -04:00
|
|
|
|
|
|
|
It is possible to block and wait until the search is completed up to a certain
|
2020-03-26 04:40:05 -04:00
|
|
|
timeout by providing the `wait_for_completion_timeout` parameter, which
|
2020-05-06 04:00:30 -04:00
|
|
|
defaults to `1` second. When the async search completes within such timeout,
|
|
|
|
the response won't include the ID as the results are not stored in the cluster.
|
|
|
|
The `keep_on_completion` parameter, which defaults to `false`, can be set to
|
|
|
|
`true` to request that results are stored for later retrieval also when the
|
|
|
|
search completes within the `wait_for_completion_timeout`.
|
2020-03-20 09:04:33 -04:00
|
|
|
|
|
|
|
You can also specify how long the async search needs to be
|
|
|
|
available through the `keep_alive` parameter, which defaults to `5d` (five days).
|
|
|
|
Ongoing async searches and any saved search results are deleted after this
|
|
|
|
period.
|
|
|
|
|
2020-03-20 10:56:49 -04:00
|
|
|
NOTE: When the primary sort of the results is an indexed field, shards get
|
|
|
|
sorted based on minimum and maximum value that they hold for that field,
|
|
|
|
hence partial results become available following the sort criteria that
|
|
|
|
was requested.
|
2020-03-20 09:04:33 -04:00
|
|
|
|
|
|
|
The submit async search API supports the same <<search-search-api-query-params,parameters>>
|
|
|
|
as the search API, though some have different default values:
|
|
|
|
|
|
|
|
* `batched_reduce_size` defaults to `5`: this affects how often partial results
|
|
|
|
become available, which happens whenever shard results are reduced. A partial
|
|
|
|
reduction is performed every time the coordinating node has received a certain
|
|
|
|
number of new shard responses (`5` by default).
|
|
|
|
* `request_cache` defaults to `true`
|
2020-03-24 12:04:38 -04:00
|
|
|
* `pre_filter_shard_size` defaults to `1` and cannot be changed: this is to
|
|
|
|
enforce the execution of a pre-filter roundtrip to retrieve statistics from
|
|
|
|
each shard so that the ones that surely don't hold any document matching the
|
|
|
|
query get skipped.
|
2020-03-20 09:04:33 -04:00
|
|
|
* `ccs_minimize_roundtrips` defaults to `false`, which is also the only
|
|
|
|
supported value
|
|
|
|
|
|
|
|
WARNING: Async search does not support <<request-body-search-scroll,scroll>>
|
|
|
|
nor search requests that only include the <<search-suggesters,suggest section>>.
|
|
|
|
{ccs} is supported only with <<ccs-min-roundtrips,`ccs_minimize_roundtrips`>>
|
|
|
|
set to `false`.
|
|
|
|
|
|
|
|
[[get-async-search]]
|
|
|
|
==== Get async search
|
|
|
|
|
|
|
|
The get async search API retrieves the results of a previously submitted
|
|
|
|
async search request given its id. If the {es} {security-features} are enabled.
|
|
|
|
the access to the results of a specific async search is restricted to the user
|
|
|
|
that submitted it in the first place.
|
|
|
|
|
|
|
|
[source,console,id=get-async-search-date-histogram-example]
|
|
|
|
--------------------------------------------------
|
|
|
|
GET /_async_search/FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued s/FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=/\${body.id}/]
|
|
|
|
|
|
|
|
[source,console-result]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
|
|
|
"id" : "FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=",
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
"is_partial" : true, <1>
|
|
|
|
"is_running" : true, <2>
|
2020-03-20 09:04:33 -04:00
|
|
|
"start_time_in_millis" : 1583945890986,
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
"expiration_time_in_millis" : 1584377890986, <3>
|
2020-03-20 09:04:33 -04:00
|
|
|
"response" : {
|
|
|
|
"took" : 12144,
|
|
|
|
"timed_out" : false,
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
"num_reduce_phases" : 46, <4>
|
2020-03-20 09:04:33 -04:00
|
|
|
"_shards" : {
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
"total" : 562, <5>
|
2020-03-20 09:04:33 -04:00
|
|
|
"successful" : 188,
|
|
|
|
"skipped" : 0,
|
|
|
|
"failed" : 0
|
|
|
|
},
|
|
|
|
"hits" : {
|
|
|
|
"total" : {
|
|
|
|
"value" : 456433,
|
|
|
|
"relation" : "eq"
|
|
|
|
},
|
|
|
|
"max_score" : null,
|
|
|
|
"hits" : [ ]
|
|
|
|
},
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
"aggregations" : { <6>
|
2020-03-20 09:04:33 -04:00
|
|
|
"sale_date" : {
|
|
|
|
"buckets" : []
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
// TESTRESPONSE[s/FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=/$body.id/]
|
|
|
|
// TESTRESPONSE[s/"is_partial" : true/"is_partial" : false/]
|
|
|
|
// TESTRESPONSE[s/"is_running" : true/"is_running" : false/]
|
|
|
|
// TESTRESPONSE[s/1583945890986/$body.start_time_in_millis/]
|
|
|
|
// TESTRESPONSE[s/1584377890986/$body.expiration_time_in_millis/]
|
|
|
|
// TESTRESPONSE[s/"took" : 12144/"took": $body.response.took/]
|
|
|
|
// TESTRESPONSE[s/"total" : 562/"total": $body.response._shards.total/]
|
|
|
|
// TESTRESPONSE[s/"successful" : 188/"successful": $body.response._shards.successful/]
|
|
|
|
// TESTRESPONSE[s/"value" : 456433/"value": $body.response.hits.total.value/]
|
|
|
|
// TESTRESPONSE[s/"buckets" : \[\]/"buckets": $body.response.aggregations.sale_date.buckets/]
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
// TESTRESPONSE[s/"num_reduce_phases" : 46,//]
|
|
|
|
|
2020-04-29 09:21:26 -04:00
|
|
|
<1> When the query is no longer running, indicates whether the search failed
|
|
|
|
or was successfully completed on all shards. While the query is being
|
|
|
|
executed, `is_partial` is always set to `true`
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
<2> Whether the search is still being executed or it has completed
|
|
|
|
<3> When the async search will expire
|
2020-04-29 09:21:26 -04:00
|
|
|
<4> Indicates how many reductions of the results have been performed. If this
|
Backport of async search changes (#53976)
* Get Async Search: omit _clusters section when empty (#53907)
The _clusters section is omitted by the search API whenever no remote clusters are searched. Async search should do the same, but Get Async Search returns a deserialized response, hence a weird `_clusters` section with all values set to `0` gets returned instead. In fact the recreated Clusters object is not the same object as the EMPTY constant, yet it has the same content.
This commit addresses this by changing the comparison in the `toXContent` method to not print out the section if the number of total clusters is `0`.
* Async search: remove version from response (#53960)
The goal of the version field was to quickly show when you can expect to find something new in the search response, compared to when nothing has changed. This can also be done by looking at the `_shards` section and `num_reduce_phases` returned with the search response. In fact when there has been one or more additional reduction of the results, you can expect new results in the search response. Otherwise, the `_shards` section could notify of additional failures of shards that have completed the query, but that is not a guarantee that their results will be exposed (only when the following partial reduction is performed their results will be available).
That said this commit clarifies this in the docs and removes the version field from the async search response
* Async Search: replicas to auto expand from 0 to 1 (#53964)
This way single node clusters that are green don't go yellow once async search is used, while
all the others still have one replica.
* [DOCS] address timing issue in async search docs tests (#53910)
The docs snippets for submit async search have proven difficult to test as it is not possible to guarantee that you get a response that is not final, even when providing `wait_for_completion=0`. In the docs we want to show though a proper long-running query, and its first response should be partial rather than final.
With this commit we adapt the docs snippets to show a partial response, and replace under the hood all that's needed to make the snippets tests succeed when we get a final response. Also, increased the timeout so we always get a final response.
Closes #53887
Closes #53891
2020-03-23 14:13:31 -04:00
|
|
|
number increases compared to the last retrieved results, you can expect
|
|
|
|
additional results included in the search response
|
|
|
|
<5> Indicates how many shards have executed the query. Note that in order for
|
|
|
|
shard results to be included in the search response, they need to be reduced
|
|
|
|
first.
|
|
|
|
<6> Partial aggregations results, coming from the shards that have already
|
2020-03-20 09:04:33 -04:00
|
|
|
completed the execution of the query.
|
|
|
|
|
2020-03-26 04:40:05 -04:00
|
|
|
The `wait_for_completion_timeout` parameter can also be provided when calling
|
|
|
|
the Get Async Search API, in order to wait for the search to be completed up
|
|
|
|
until the provided timeout. Final results will be returned if available before
|
|
|
|
the timeout expires, otherwise the currently available results will be
|
|
|
|
returned once the timeout expires. By default no timeout is set meaning that
|
|
|
|
the currently available results will be returned without any additional wait.
|
2020-03-20 09:04:33 -04:00
|
|
|
|
|
|
|
The `keep_alive` parameter specifies how long the async search should be
|
|
|
|
available in the cluster. When not specified, the `keep_alive` set with the
|
|
|
|
corresponding submit async request will be used. Otherwise, it is possible to
|
|
|
|
override such value and extend the validity of the request. When this period
|
|
|
|
expires, the search, if still running, is cancelled. If the search is
|
|
|
|
completed, its saved results are deleted.
|
|
|
|
|
|
|
|
[[delete-async-search]]
|
|
|
|
==== Delete async search
|
|
|
|
|
|
|
|
You can use the delete async search API to manually delete an async search
|
|
|
|
by ID. If the search is still running, the search request will be cancelled.
|
|
|
|
Otherwise, the saved search results are deleted.
|
|
|
|
|
|
|
|
[source,console,id=delete-async-search-date-histogram-example]
|
|
|
|
--------------------------------------------------
|
|
|
|
DELETE /_async_search/FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued s/FmRldE8zREVEUzA2ZVpUeGs2ejJFUFEaMkZ5QTVrSTZSaVN3WlNFVmtlWHJsdzoxMDc=/\${body.id}/]
|