We currently have a very high value of 60s, due to calls to the health API where we indeed may have to wait this long.

If per-request timeouts are added to Jest (https://github.com/searchbox-io/Jest/issues/411), we could use that instead and avoid this high default read timeout.

We asked for per-request timeouts to be added to the official Elasticsearch client, so let's wait for that first.

It looks like it's not going to happen. Let's try another way: use a lower read timeout by default, but implement health checks in Hibernate Search so that we try again on read timeout, until the health check timeout is reached. For an idea of how to do this, see how we used to trigger a refresh after a flush; the code was removed, but you will probably need to reintroduce it: https://github.com/hibernate/hibernate-search/commit/cefff76cca94f1aa941736ffae14320dadd072fb

Also, I've read somewhere that the health check after creating an index is no longer necessary in Elasticsearch 5 onwards; let's investigate that?