How does rest-high-level client retries?

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):

server - OpenSearch 2.5.0
client - Java High Level Rest Client 2.5.0 (github)


(Relevant) Question 1 : Even though not well documented (or hard to find), Elasticsearch high level client has a retry logic based on failover (in embedded low level client). See posts from Github and the forum respectively; [1] and [2] Does OpenSearch Java high level client have the same retry logic as Elasticsearch client?

(More Important) Question 2 : If the retry logic works the same (failover), does it fail faster when we execute the same, very recently failed, query?

Referenced Links :
[1] -
[2] -

The opensearch-java client is a fork of the elasticsearch-java client from before the discussion you linked, and no retry logic has been added post-fork. I don’t know about the high-level rest client.

If you could share more about your use case, there might be other options, such as flink or data-prepper, where someone has already written retry logic that wraps the client.

We are trying to migrate from Elasticsearch (6.8.22) to OpenSearch (2.5.0). So, what we are trying to do is achieving a similar behaviour without touching client-side application logic much. Currently, our application is writing to both Elasticsearch and OpenSearch (over a proxy).

Sorry if I added confusion. We don’t use or plan to use the opensearch-java client before our migration is completed. I have added opensearch-java discussion link only for referencing the sentence below :
“The Low Level Client also does retry when configured when several nodes: on network failure, it will retry up to the number of nodes.”

Otherwise, we use high-level rest client.

The answers for the future readers of this topic :

Answer for Q1 : Yes, the clients, both ES and OS, have the same logic with minor differences. AWS support pointed out that OpenSearch high-level REST client v2.5.0 is practically the fork of Elasticsearch high-level REST client v.7.10.12. In our case, we didn’t configure the client properly for retries/failovers to start with, so both clients didn’t utilise retries at all.

Answer for Q2 : We decided to wrap the client with an external retrier since we discovered that the client itself doesn’t retry at all. So, this question stays an unknown for us. However, since we have a workaround (no failover + external retrier), there will be no more follow ups from our side.


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.