Async/Availability of a Doc Update via Get (Java API)

In a simple 3 node cluster (all nodes master eligible, one elected master) I'm seeing some strange results when updating documents via Java API. It appears as though rapid updates to the same document via many concurrent threads may be causing some of them to see an older/stale version of the document.

In a nutshell my update method first acquires a site-wide lock, then retrieves the document from elastic (via GetRequestBuilder), updates the document, then saves it back again (via UpdateRequestBuilder), and finally releases the lock. I may have up to 10 concurrent threads trying to do this upwards of 100 times.

I suppose my first question is, if making an update to a document via UpdateRequestBuilder.get() will that call happen asynchronously and return control to my Java thread immediately, or will it block until the update is finished?

Secondly, even if that call blocks is there any chance that a subsequent call via Java API GetRequestBuilder.get() might return the old/stale version of the document if the calls are happening quickly enough?

Again this has nothing to do with searching, these are straight update & get calls being performed via the document's ID (though it may be worth mentioning this is happening during a heavy indexing time and the refresh rate is set to "-1").

Thanks so much for any help!

It turns out the issue had to do with the site-wide application locking (which was not configured correctly). I believe this will address my issue however I would still appreciate answers to my questions to further my understanding of the update/get cycle.

Thanks!

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