ES Version: 2.3.2
Nest Version: 2.3.2
OS: Windows Core 2012 R2
We're sending bulk index requests with default thread pool settings and queue size. Within the client code we check for itemsWithErros and retry the bulk operation. Suprisingly, for the items that got rejected by Queue capacity error, threw version conflict error on second try.
Our understanding is, if the bulk request is rejected that means it never reached to ES and hence the version is not incremented. After digging the code a little bit, I found BackOffPolicy.java that is set within BulkRequestHandler class. The back off policy has maxNumberOfRetries as one of the argument within it's constructor and other being Time.
We also do set MaximumRetries(5) method on ConnectionSettings in Elasticsearch NEST. I was just wondering whther this setting results in internal retry logic while doing bulk requests?
If this is the case, then the initial bulk document that threw ESRejectedException would have gone through by Retry method? If yes, then it makes sense to get version conflict error when sending the same failed items again to ES.