honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/migration/migrate_7_0/restclient.asciidoc

24 lines
1.0 KiB
Plaintext
Raw Normal View History

[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
REST high-level Client: remove deprecated API methods (#31200) This commit removes all the API methods that accept a `Header` varargs argument, in favour of the newly introduced API methods that accept a `RequestOptions` argument. Relates to #31069
2018-06-12 15:00:06 -04:00
[[breaking_70_restclient_changes]]
=== High-level REST client changes
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
REST high-level Client: remove deprecated API methods (#31200) This commit removes all the API methods that accept a `Header` varargs argument, in favour of the newly introduced API methods that accept a `RequestOptions` argument. Relates to #31069
2018-06-12 15:00:06 -04:00
==== API methods accepting `Header` argument have been removed
All API methods accepting headers as a `Header` varargs argument, deprecated
since 6.4, have been removed in favour of the newly introduced methods that
accept instead a `RequestOptions` argument. In case you are not specifying any
header, e.g. `client.index(indexRequest)` becomes
`client.index(indexRequest, RequestOptions.DEFAULT)`.
In case you are specifying headers
e.g. `client.index(indexRequest, new Header("name" "value"))` becomes
REST hl client: cluster health to default to cluster level (#31268) With #29331 we added support for the cluster health API to the high-level REST client. The transport client does not support the level parameter, and it always returns all the info needed for shards level rendering. We have maintained that behaviour when adding support for cluster health to the high-level REST client, to ease migration, but the correct thing to do is to default the high-level REST client to `cluster` level, which is the same default as when going through the Elasticsearch REST layer.
2018-06-13 09:06:13 -04:00
`client.index(indexRequest, RequestOptions.DEFAULT.toBuilder().addHeader("name", "value").build());`
[DOCS] Synchronize location of Breaking Changes (#33588)
2018-09-27 11:41:38 -04:00
[float]
REST hl client: cluster health to default to cluster level (#31268) With #29331 we added support for the cluster health API to the high-level REST client. The transport client does not support the level parameter, and it always returns all the info needed for shards level rendering. We have maintained that behaviour when adding support for cluster health to the high-level REST client, to ease migration, but the correct thing to do is to default the high-level REST client to `cluster` level, which is the same default as when going through the Elasticsearch REST layer.
2018-06-13 09:06:13 -04:00
==== Cluster Health API default to `cluster` level
The Cluster Health API used to default to `shards` level to ease migration
from transport client that doesn't support the `level` parameter and always
returns information including indices and shards details. The level default
Remove support for maxRetryTimeout from low-level REST client (#38085) We have had various reports of problems caused by the maxRetryTimeout setting in the low-level REST client. Such setting was initially added in the attempts to not have requests go through retries if the request already took longer than the provided timeout. The implementation was problematic though as such timeout would also expire in the first request attempt (see #31834), would leave the request executing after expiration causing memory leaks (see #33342), and would not take into account the http client internal queuing (see #25951). Given all these issues, it seems that this custom timeout mechanism gives little benefits while causing a lot of harm. We should rather rely on connect and socket timeout exposed by the underlying http client and accept that a request can overall take longer than the configured timeout, which is the case even with a single retry anyways. This commit removes the `maxRetryTimeout` setting and all of its usages.
2019-02-06 02:43:47 -05:00
value has been aligned with the Elasticsearch default level: `cluster`.