Is indices.refresh a blocking method?

[boguth]

This question was not clearly answered in this issue: #308 and it's the only resource I've found that addresses the overall question about concurrency issues with elastic search.

So, definitively, is indices.refresh a blocking method? By that I mean does indices.refresh block the executing thread until its operation finished - like sleep (http://apidock.com/ruby/Kernel/sleep) does, for example.

Like the dev in the issue mentioned above, I'm having issues obtaining fresh data in real time. If indices.refresh isn't a viable solution to concurrency issues, what is?

[karmi]

Hi, indices.refresh is indeed a blocking method, ie. it will not return until the operation has finished or the timout has been met.

It is debatable what is "obtaining fresh data in realtime" though: as a solution for something like an integration test, it is 100% the correct method. As a solution for an application logic, where you would call index refresh eg. after any save operation, not so much.

[boguth]

@karmi Fantastic. Thanks so much.

[boguth]

@karmi One more: Will this lock the indices so that no other queries can get information from elastic search until this method is complete? For example, if I call this method and then asynchronously query elastic search, will indices.refresh prevent the asynchronous query from retrieving information until it returns? Is it atomic?

[karmi]

No, it won't lock anything for reading or writing -- it's just that until the refresh operation has completed (either the manual or automatic, going on every 1sec by default), the reads won't see the changes.

[boguth]

Thanks for your quick response, karmi. Appreciate you helping out an elastic search newbie. Take care.