# UpdateRequest upsert with retryOnConflict using BulkProcessor failed **URL:** \ **Category:** Elasticsearch\ **Created:** [May 23, 2019, 1:45pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455 "2019-05-23T13:45:37Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![edumucelli](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/edumucelli/32/46725_2.png) [@edumucelli](https://discuss.elastic.co/u/edumucelli)\ **Post date:** [May 23, 2019, 1:45pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/1 "2019-05-23T13:45:38Z")
Althought ES [documentation](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high-document-update.html#_optional_arguments_3) and [staff](https://discuss.elastic.co/t/version-conflict-coming-without-passing-version-es-5-6/132248/2) suggests using `retry_on_conflict` to mitigate version conflict, this feature is broken. I am using High Level Client 6.6.1 and here is the way I am building the request: ``` IndexRequest indexRequest = new IndexRequest(MY_INDEX, MY_MAPPING, myId) .source(gson.toJson(entity), XContentType.JSON); UpdateRequest updateRequest = new UpdateRequest(MY_INDEX, MY_MAPPING, myId) .retryOnConflict(3) .doc(indexRequest) .upsert(indexRequest); ``` Without `.retryOnConflict(3)` it will "work", but some queries will complain about version conflict. I create multiple of those requests and then process it with `client.bulk(request, RequestOptions.DEFAULT);` However when I add `.retryOnConflict(3)` as shown above it completely breaks with the following stacktrace: ``` ElasticsearchStatusException[Elasticsearch exception [type=illegal_argument_exception, reason=Action/metadata line [1] contains an unknown parameter [retry_on_conflict]]] at org.elasticsearch.rest.BytesRestResponse.errorFromXContent(BytesRestResponse.java:177) at org.elasticsearch.client.RestHighLevelClient.parseEntity(RestHighLevelClient.java:2050) at org.elasticsearch.client.RestHighLevelClient.parseResponseException(RestHighLevelClient.java:2026) at org.elasticsearch.client.RestHighLevelClient.internalPerformRequest(RestHighLevelClient.java:1775) at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:1732) at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:1694) at org.elasticsearch.client.RestHighLevelClient.bulk(RestHighLevelClient.java:470) ``` Someone else already posted kind of [same question](https://discuss.elastic.co/t/updaterequest-with-retryonconflict-using-bulkprocessor-failed/138273) before but unfortunately no response has been provided. Is there a way to overcome this problem? Should I manually retry the query? ---
**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\ **Post date:** [May 23, 2019, 2:21pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/2 "2019-05-23T14:21:29Z")
Hmm, this looks like a bug, possibly in the HLRC itself. Would you mind opening a ticket in the ES repo? ---
**Author:** ![edumucelli](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/edumucelli/32/46725_2.png) [@edumucelli](https://discuss.elastic.co/u/edumucelli)\ **Post date:** [May 23, 2019, 2:22pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/3 "2019-05-23T14:22:25Z")
Alright, I will do it. Thanks! ---
**Author:** ![edumucelli](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/edumucelli/32/46725_2.png) [@edumucelli](https://discuss.elastic.co/u/edumucelli)\ **Post date:** [May 24, 2019, 2:29pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/4 "2019-05-24T14:29:11Z")
Further investigating I am wondering if the problem is actually due to the backend and high level client version mismatch. I have done those requests using High Level Rest Client 6.6.1 but using ES backend 5.5.3. Would you think there could exist such incompatibility? Thanks! ---
**Author:** ![yelin](https://avatars.discourse-cdn.com/v4/letter/y/e274bd/32.png) [@yelin](https://discuss.elastic.co/u/yelin)\ **Post date:** [May 24, 2019, 2:56pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/5 "2019-05-24T14:56:16Z")
I got similar issue before even though we're using both 6.x server & client, reported on the forum but didn't get any feedback. As I'm using org.elasticsearch.action.bulk.BulkProcessor, for which alternatively you can set the number of retries through BulkProcessor.Builder.setBackoffPolicy() (example at [https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high-document-bulk.html#java-rest-high-document-bulk-processor](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high-document-bulk.html#java-rest-high-document-bulk-processor)). However, for you to be aware of, there is another bug on the BulkProcessor reported at [BulkProcessor hangs instead of timeout](https://discuss.elastic.co/t/bulkprocessor-hangs-instead-of-timeout/147737), which doesn't seem resolved yet ☹ ---
**Author:** ![edumucelli](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/edumucelli/32/46725_2.png) [@edumucelli](https://discuss.elastic.co/u/edumucelli)\ **Post date:** [May 24, 2019, 3:27pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/6 "2019-05-24T15:27:41Z")
Thanks for the info! Unfortunately I am not using `BulkProcessor` just the High Level client's `client.bulk` method. Considering what you have said there is not another way around to set a retry policy. I will probably come up with some home-made thing using [Failsafe](http://jodah.net/failsafe/javadoc/net/jodah/failsafe/RetryPolicy.html). ---
**Author:** ![polyfractal](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/polyfractal/32/48162_2.png) [@polyfractal](https://discuss.elastic.co/u/polyfractal)\ **Post date:** [May 28, 2019, 1:56pm UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/7 "2019-05-28T13:56:30Z")
Possibly... but I would be surprised. The HLRC just emits JSON and uses the standard REST endpoints, and "retry\_on\_conflict" has been in the REST endpoint for ages. That's actually the main reason we are moving to the HLRC, so that strict versioning becomes a bit more decoupled in java clients (like other languages, python/ruby/php/etc). As long as the JSON is valid for the endpoint the backend and client don't necessarily have to be on the same version. So I think it's something about the HLRC, either emitting a bad parameter, or unable to parse the response, which is causing the issue. But.... that's without looking into the issue at all, just a guess 🙂 ---
**Author:** ![edumucelli](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/edumucelli/32/46725_2.png) [@edumucelli](https://discuss.elastic.co/u/edumucelli)\ **Post date:** [June 19, 2019, 10:15am UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/8 "2019-06-19T10:15:32Z")
I was finally able to narrow it down. By updating backend to 6.7 the problem has gone. So in my case having a backend 5.5.3 and client 6.7.2 breaks, but when I have aligned both backend and client on 6.7.2 it worked. Some imcompatible behavior is there, but I was not able yet to precisely find it. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 17, 2019, 10:17am UTC](https://discuss.elastic.co/t/updaterequest-upsert-with-retryonconflict-using-bulkprocessor-failed/182455/9 "2019-07-17T10:17:39Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.