spring data elasticsearch uses 7.x client version and my production elasticsearch version is 6.4.2. So I changed the version and got the following exception. How to safely change version in spring data es?
Repopsitory: https://github.com/Yungdi/spring-data-reactive-elasticsearch
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.<init>(ReactiveElasticsearchTemplate.java:108)
The following method did not exist:
org.elasticsearch.action.support.IndicesOptions.strictExpandOpenAndForbidClosedIgnoreThrottled()Lorg/elasticsearch/action/support/IndicesOptions;
The method's class, org.elasticsearch.action.support.IndicesOptions, is available from the following locations:
jar:file:/Users/we/DevEnv/gradle-6.4.1/caches/modules-2/files-2.1/org.elasticsearch/elasticsearch/6.4.2/29a4003b7e28ae8d8896041e2e16caa7c4272ee3/elasticsearch-6.4.2.jar!/org/elasticsearch/action/support/IndicesOptions.class
The class hierarchy was loaded from the following locations:
org.elasticsearch.action.support.IndicesOptions: file:/Users/we/DevEnv/gradle-6.4.1/caches/modules-2/files-2.1/org.elasticsearch/elasticsearch/6.4.2/29a4003b7e28ae8d8896041e2e16caa7c4272ee3/elasticsearch-6.4.2.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.elasticsearch.action.support.IndicesOptions
You can’t use a Elasticsearch 6 cluster with Spring Data Elasticsearch 4 which uses Elasticsearch 7 libraries. The Elasticsearch REST API that is used had breaking changes between version 6 and 7.
You can try to use Spring Data Elasticsearch 3.2.x which targets 6.8; I currently don’t know if there were breaking changes between Elasticsearch 6.4 and 6.8, you’ll have to try it.
Related
Currently we are on spring-data-elasticsearch 3.2.6 + elasticsearch 6.8.
We are moving to new elasticsearch 7.x. Do I have to update spring-data-elasticsearch to 4.x? We only use ElasticsearchRepository in spring-data-elasticsearch. And we don't need to use any new feature in elasticsearch 7.x.
If we are moving to elasticsearch 8.x in the future, do I need update spring-data-elasticsearch ?
Update:
What Elasticsearch client does Spring-Data-Elasticsearch use under the hood?
All methods in the `ElasticsearchRepository` are deprecated. What should do I use?
I found some discussions in above threads. Here is my summary.
Operations with Templates:
ElasticsearchTemplate implements ElasticSearchOperation. It uses TransportClient(which is deprecated in ES 7 and has been removed in ES8)
ElasticsearchRestTemplate implements ElasticSearchOperation. It uses high level client(which is deprecated in ES 7.16.0. It will be removed in future. #Deprecated(since = "7.16.0", forRemoval = true) )
ReactiveElasticsearchTemplate implements ReactiveElasticsearchOperations. It uses Reactive Client.
Repository
ElasticsearchRepository uses TransportClient as default. All methods in the ElasticsearchRepository are deprecated now.
Reactive Elasticsearch repository builds on ReactiveElasticsearchOperations.
Due to underlying TransportClient or HigLevelRestClient has been deprecated, can I conclude that the correct way is to use Reactive Client(ReactiveElasticsearchTemplate or Reactive Elasticsearch repository) ?
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.
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.hibernate.search.elasticsearch.client.impl.DefaultElasticsearchClientFactory.createClient(DefaultElasticsearchClientFactory.java:92)
The following method did not exist:
org.elasticsearch.client.RestClientBuilder.setMaxRetryTimeoutMillis(I)Lorg/elasticsearch/client/RestClientBuilder;
The method's class, org.elasticsearch.client.RestClientBuilder, is available from the following locations:
jar:file:/home/temp/.gradle/caches/modules-2/files-2.1/org.elasticsearch.client/elasticsearch-rest-client/7.10.2/d0c857275bcec532079cdabb7913e2611c123e70/elasticsearch-rest-client-7.10.2.jar!/org/elasticsearch/client/RestClientBuilder.class
The class hierarchy was loaded from the following locations:
org.elasticsearch.client.RestClientBuilder:
file:/home/temp/.gradle/caches/modules-2/files-2.1/org.elasticsearch.client/elasticsearch-rest-client/7.10.2/d0c857275bcec532079cdabb7913e2611c123e70/elasticsearch-rest-client-7.10.2.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.elasticsearch.client.RestClientBuilder*
We need to use elasticsearch version 7.10.2 and currently we are using springboot version 2.3.9
any help?
is this correct mapping in application.yaml file for elastic search 7.10.2
hibernate:
format_sql: true
search.default:
elasticsearch:
dynamic_mapping: true
index_schema_management_strategy: update
required_index_status: yellow
https://stackoverflow.com/users/6692043/yrodiere
The version of the elasticsearch-rest-client dependency (Elasticsearch's low-level REST client) does not have to match the version of Elasticsearch server you actually use. elasticsearch-rest-client 7.16.3 will talk just fine to Elasticsearch server 7.10.2. And elasticsearch-rest-client 7.16.3 is licensed under ASL 2.0, if that's what you're worried about.
So, in short: do what the Hibernate Search documentation suggests, and upgrade to the latest version of elasticsearch-rest-client. See https://docs.jboss.org/hibernate/search/6.1/reference/en-US/html_single/#gettingstarted-framework-spring-boot-dependency-versions :
Spring Boot automatically sets the version of dependencies without your knowledge. While this is ordinarily a good thing, from time to time Spring Boot dependencies will be a little out of date. Thus, it is recommended to override Spring Boot’s defaults at least for some key dependencies.
With Maven, add this to your POM’s :
<properties>
<hibernate.version>5.6.5.Final</hibernate.version>
<elasticsearch.version>7.16.3</elasticsearch.version>
<!-- ... plus any other properties of yours ... -->
</properties>
If you use Elasticsearch's high-level REST client, now... you're in a pickle. That client is no longer open-source and can cause licensing issues. And its last open-source version (7.10.something) may not work with elasticsearch-rest-client 7.16.3. So if you really need to stick with version 7.10 or earlier of the high-level REST client, then you'll need to use older versions of elasticsearch-rest-client and Hibernate Search.
We have a java application (spring boot + hibernate search + elastic search).
Application is working fine on elastic search version 6.8
Recently, we have created a new cluster in aws with version 7.10.2 and updated elastic search endpoint in my java application.
After updating the elastic search endpoint I am getting error Can't update put mapping Types cannot be provided in put mapping requests, unless the include_type_name parameter is set to true and due to this unable to start the server.
I am not sure where to set include_type_name=true because all the indexes gets created automatically with #Indexed.
Can someone please let us know how can we fix this issue ?
Thanks #yrodiere for your response.
I tried to upgrade below dependencies version but unfortunately not able to fix it.
Previous Version:
compile 'org.hibernate:hibernate-search-orm:5.9.3.Final'
compile 'org.hibernate:hibernate-search-elasticsearch:5.9.3.Final'
compile 'org.hibernate:hibernate-search-elasticsearch-aws:5.9.3.Final'
Updated version :
compile 'org.hibernate:hibernate-search-orm:5.9.3.Final
compile 'org.hibernate.search:hibernate-search-backend-elasticsearch:6.1.1.Final'
compile 'org.hibernate.search:hibernate-search-backend-elasticsearch-aws:6.1.1.Final'
Note: If I downgrade this org.hibernate:hibernate-search-orm:5.9.3.Final then getting CE
am i missing something?
You're probably using Hibernate Search 5.x. In Hibernate Search 5.x, the Elasticsearch integration was experimental and only compatible with Elasticsearch up to version 5.6.
The fact that your application was working fine with Elasticsearch 6.8 was pure luck: Hibernate Search 5.x was never intended to work with Elasticsearch 6+.
To upgrade to a more recent version of Elasticsearch, you must upgrade to Hibernate Search 6.0 (or later). The API is different, but there is a very detailed migration guide, and at least you will get production-ready (non-experimental) Elasticsearch integration (plus tons of improvements).
Note that Hibernate Search 6.x also requires upgrading to Hibernate ORM 5.4; see this compatibility matrix.
I was reading https://www.elastic.co/blog/deprecating-rivers which stats that ES rivers (plugin) are getting deprecated. i.e. any plugin directly integrated with ElasticSearch server will no longer work beyond ES 3.x onwards.
Couchbase plugin is one of those kind.
I searched all the documents of couchbase plugin at http://developer.couchbase.com/documentation/server/4.5/connectors/elasticsearch-2.1/elastic-intro.html but could not find if they are using deprecated way or not?
Does anyone know? Should we keep using couchbase plugin or should start planning to write data directly to ES using our application.
We have couchbase data getting replicated to ES using couchbase plugin and XDCR.
I'm the maintainer of the Couchbase ES transport plugin. As Roi mention in his answer, the plugin doesn't use rivers, so it won't be deprecated. It currently supports any version of ES from 1.3 to 2.x, and I'm working on adding support for 5.x. It's taking a bit longer, because ES 5.x broke some configuration sharing features in unexpected ways.
I'd suggest always looking at our github repo for the latest plugin releases:
https://github.com/couchbaselabs/elasticsearch-transport-couchbase
The Couchbase plugin is not using Rivers, there is another River plugin which is not longer valid.
take a look here: https://github.com/couchbaselabs/elasticsearch-transport-couchbase
I am trying to integrate Apache Nutch 2.2.1 with Elasticsearch 0.90.11.
I have followed all tutorials available (although there are not so many) and even changed bin/crawl.sh to use elasticsearch to index instead of solr.
It seems that all works when I run the script until elasticsearch is trying to index the crawled data.
I checked hadoop.log inside logs folder under nutch and found the following errors:
Error injecting constructor, java.lang.NoSuchFieldError: STOP_WORDS_SET
Error injecting constructor, java.lang.NoClassDefFoundError: Could not initialize class org.apache.lucene.analysis.en.EnglishAnalyzer$DefaultSetHolder
If you managed to get it working I would very much appreciate the help.
Thanks,
Andrei.
Having never used Apache Nutch, but briefly reading about it, I would suspect that your inclusion of Elasticsearch is causing a classpath collision with a different version of Lucene that is also on the classpath. Based on its Maven POM, which does not specify Lucene directly, then I would suggest only including the Lucene bundled with Elasticsearch, which should be Apache Lucene 4.6.1 for your version.
Duplicated code (differing versions of the same jar) tend to be the cause of NoClassDefFoundError when you are certain that you have the necessary code. Based on the fact that you switched from Solr to Elasticsearch, then it would make sense that you left whatever jars from Solr on your classpath, which would cause the collision at hand. The current release of Solr is 4.7.0, which is the same as Lucene and that would collide with 4.6.1.