spring-data-elasticsearch | Provide support to increase developer productivity in Java when using Elasticsearch. Uses familiar S | Microservice library

The new Elasticsearch would be 8.

Val already put the link to the compatibility matrix in his comment.

Version 3.2.6 is pretty outdated (March 25 2020) and out of support since October 2020.

The first thing you can try is to see if your application works with a 7 cluster - although I doubt that, I can't tell you exactly what had changed in the API, but there was quite some stuff.

What you should not do is putting newer Elasticsearch libraries on the classpath than the ones that Spring Data Elasticsearch was built with, this will in most cases make problems.

But I'd recommend to upgrade your application anyway and keep it regularly up to date.

As for future upgrade to version 8: It is possible to send a compatibility header in your requests (this can be done in Spring Data Elasticsearch 4) and the Elasticsearch cluster should respond in a format that is compatible with a client expecting version 7. I wrote should, because it does not conform to this in every case - I reported one case that is fixed now. But I wouldn't rely on that.

Again, please update your application and keep it up to date, not only because of Spring Data Elasticsearch, but also because these updates always include bug and/or security fixes.

ConnectionClosedException seems to hint at the fact that your Spring Boot application cannot establish a connection to your ES cluster.

It looks like you're using ES8, which has SSL/TLS on by default, so you would need to configure your Spring Boot application to use SSL instead.

At 6:00 into the video, elasticsearch.url in application.properties should be https://localhost:9200 instead of just localhost:9200.

However, as of March 15th 2022, it doesn't seem like ES 8 is supported by Spring Data ES yet, you might need to revert to the ES 7.15+ release.

Spring Data Elasticsearch internally builds a CriteriaQuery for a repository method that has StartingWith in in it's name:

https://github.com/spring-projects/spring-data-elasticsearch/blob/main/src/main/java/org/springframework/data/elasticsearch/repository/query/parser/ElasticsearchQueryCreator.java#L113-L116:

You have to configure to use SSL for the reactive client with one of the usingSsl()methods:

I am currently working on integrating the new Elasticsearch client in Spring Data Elasticsearch. We will in the next minor release (4.4) still the RestHighLevelClient but provide as an optional alternative the possibility to use the new client.

The new client does not yet have the same functionality as the RHLC and still has some error (you might want to have a look at it's issue list), so we cannot already replace it, but the most important reason not to use it in the current version is that the new Client pulls in jakarta packages instead of javax and switching by default to the new client would break many existing applications.

A full replacement cannot be done before Spring Data Elasticsearch 5.0, which will use Spring 6, be integrated in Spring Boot 3 as Jakarta EE9 will be only with these releases.

In my opinion, Elasticsearch should not have deprecated the RHLC in a switch of a minor version (ES 7.15 -> 7.16) while providing an incomplete alternative that introduces breaking changes.

So for the time being we have to live with the fact that Spring Data Elasticsearch needs to use a deprecated class.

Nothing out of the box.

One idea (I did not try it out): You'd need to create your own implementation of the ElasticsearchOperations interface, lets call it MyOperations and return that from the AbstractElasticsearchConfiguration#elasticsearchOperations() method which your configuration inherits. In this MyOperations implementation (which is a singleton Spring bean), you'd create a delegate ElasticsearchOperations with the same code like in the configuration class that is connected to normal cluster. Every method in your implementation then delegates to the corresponding method of the delegate.

In the failure case, your implementation would create a new delegate that now connects to the secondary cluster and replace the first one with it. Or create both and implement a toggle feature to switch between the two.

These are different things. refresh (aka refreshPolicy) lets you tell ES to start a refresh after indexing and wait for it to complete (wait_for) or not wait (true) or just leave cluster do its job (false, None, default).

refresh_interval makes most sense when refresh is not enabled and it defines how exactly cluster "does its job". Refresh is quite heavy operation so it's recommended to increase it or even disable (set to -1) for the time of indexing.

If you haven't noticed performance improvement while changing refresh_interval then you probably haven't maxed out indexing capacity on ES side: bulk size tuning, multiple indexing threads/machines, etc (see Tune for indexing speed)

The ccs_minimize_roundtrips parameter has been added in 7.0.0-beta1, so my take is that you're using a client version that is more recent (i.e. 7+) than your Elasticsearch server version.

According to your Maven dependencies, spring-data-elasticsearch:3.2.3 depends on Elastic 6.8.12, so there is a small disconnect between the client and server versions.

Your top level query should be a bool query with two entries as must:

• the first for the name that would be the one you already have.
• the second for the "status.id" property