# Knowing when and when not to retry a request based on ElasticsearchException or IOException with the RestHighLevelClient **URL:** \ **Category:** Elasticsearch\ **Created:** [May 31, 2019, 6:01pm UTC](https://discuss.elastic.co/t/knowing-when-and-when-not-to-retry-a-request-based-on-elasticsearchexception-or-ioexception-with-the-resthighlevelclient/183779 "2019-05-31T18:01:34Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Forrest\_Townsend](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/forrest_townsend/32/44609_2.png) [@Forrest\_Townsend](https://discuss.elastic.co/u/Forrest_Townsend)\ **Post date:** [May 31, 2019, 6:01pm UTC](https://discuss.elastic.co/t/knowing-when-and-when-not-to-retry-a-request-based-on-elasticsearchexception-or-ioexception-with-the-resthighlevelclient/183779/1 "2019-05-31T18:01:34Z")
I would like to build in some retry logic on our Elasticsearch requests but I cannot find documentation to explain WHEN a request should be submitted again after a short delay. Also knowing if you are supposed to retry IOExceptions or only certain ones.. This is the only documentation that I found describing the errors (src: [Bulk API | Java REST Client [6.8] | Elastic](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/6.8/java-rest-high-document-bulk.html#java-rest-high-document-bulk-sync)) > Synchronous calls may throw an `IOException` in case of either failing to parse the REST response in the high-level REST client, the request times out or similar cases where there is no response coming back from the server. In cases where the server returns a `4xx` or `5xx` error code, the high-level client tries to parse the response body error details instead and then throws a generic `ElasticsearchException` and adds the original `ResponseException` as a suppressed exception to it. But there are no documents that explain what error codes are deemed okay to retry and which ones are errors that cannot be retried? Any help would be greatly appreciated. Thanks! ---
**Author:** ![jakelandis](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jakelandis/32/36163_2.png) [@jakelandis](https://discuss.elastic.co/u/jakelandis)\ **Post date:** [May 31, 2019, 7:23pm UTC](https://discuss.elastic.co/t/knowing-when-and-when-not-to-retry-a-request-based-on-elasticsearchexception-or-ioexception-with-the-resthighlevelclient/183779/2 "2019-05-31T19:23:56Z")
How to handle the errors may be use case specific if you want/need to retry. You can take a look at how Logstash implements retry here: [https://github.com/logstash-plugins/logstash-output-elasticsearch/blob/master/lib/logstash/outputs/elasticsearch/common.rb#L225](https://github.com/logstash-plugins/logstash-output-elasticsearch/blob/master/lib/logstash/outputs/elasticsearch/common.rb#L225) In summary Logstash retries anything that is not a `409` (conflict), `400`(bad request) or `404` (missing) . Logstash also implements an incremental back off when retrying with continued failures which helps keep things healthy especially when Elasticsearch is pushing back with `429` (too many requests). This is pretty good general retry policy. However, if for example, you know all requests should authorized, you may not want to retry `401` or `403`s. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [June 28, 2019, 7:23pm UTC](https://discuss.elastic.co/t/knowing-when-and-when-not-to-retry-a-request-based-on-elasticsearchexception-or-ioexception-with-the-resthighlevelclient/183779/3 "2019-06-28T19:23:57Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.