API Java ElasticSearch: NoNodeAvailableException: aucun noeud disponible

public static void main(Ssortingng[] args) throws IOException { Settings settings = ImmutableSettings.settingsBuilder() .put("cluster.name", "foxzen") .put("node.name", "yu").build(); Client client = new TransportClient(settings) .addTransportAddress(new InetSocketTransportAddress("XXX.XXX.XXX.XXX", 9200)); // XXX is my server's ip address IndexResponse response = client.prepareIndex("twitter", "tweet") .setSource(XContentFactory.jsonBuilder() .startObject() .field("productId", "1") .field("productName", "XXX").endObject()).execute().actionGet(); System.out.println(response.getIndex()); System.out.println(response.getType()); System.out.println(response.getVersion()); client.close(); } 

J’accède au serveur depuis mon ordinateur

 curl -get http://XXX.XXX.XXX.XXX:9200/ 

obtenir ceci

 { "status" : 200, "name" : "yu", "version" : { "number" : "1.1.0", "build_hash" : "2181e113dea80b4a9e31e58e9686658a2d46e363", "build_timestamp" : "2014-03-25T15:59:51Z", "build_snapshot" : false, "lucene_version" : "4.7" }, "tagline" : "You Know, for Search" } 

Pourquoi avoir une erreur en utilisant l’API Java?

MODIFIER

Il y a la configuration du cluster et du nœud de elasticsearch.yml

 ################################### Cluster ################################### # Cluster name identifies your cluster for auto-discovery. If you're running # multiple clusters on the same network, make sure you're using unique names. # cluster.name: foxzen #################################### Node ##################################### # Node names are generated dynamically on startup, so you're relieved # from configuring them manually. You can tie this node to a specific name: # node.name: yu 

Quelques suggestions:

1 – Utilisez le port 9300. [9300-9400] concerne la communication noeud à noeud, [9200-9300] le trafic HTTP.

2 – Assurez-vous que la version de l’API Java que vous utilisez correspond à la version de elasticsearch exécutée sur le serveur.

3 – Assurez-vous que le nom de votre cluster est foxzen (vérifiez le foxzen sur le serveur).

4 – Supprimez put("node.name", "yu") , vous ne rejoignez pas le cluster en tant que noeud car vous utilisez le TransportClient , et même si vous étiez, il semblerait que votre noeud de serveur soit nommé yu . un nom de noeud différent dans tous les cas.

Vous devez changer votre code pour utiliser le port 9300 – la bonne ligne serait:

  Client client = new TransportClient(settings) .addTransportAddress(new InetSocketTransportAddress("XXX.XXX.XXX.XXX", 9300)); 

La raison en est que l’API Java utilise le transport interne utilisé pour les communications entre nœuds et que le port 9300 est utilisé par défaut. Le port 9200 est l’interface par défaut de l’interface de l’API REST. Problème courant: consultez cet exemple de code ici, au bas de la page, sous Transport Client:

http://www.elasticsearch.org/guide/en/elasticsearch/client/java-api/current/client.html

 // on startup Client client = new TransportClient() .addTransportAddress(new InetSocketTransportAddress("host1", 9300)) .addTransportAddress(new InetSocketTransportAddress("host2", 9300)); // on shutdown client.close(); 

J’ai rencontré cette erreur aussi. J’utilise ElasticSearch 2.4.1 en tant que serveur autonome (nœud unique) dans docker, en programmant avec Grails 3 / spring-data-elasticsearch. Mon correctif est de définir client.transport.sniff sur false . Voici ma conf de base:

application.yml

 spring.data.elasticsearch: cluster-name: "my-es" cluster-nodes: "localhost:9300" properties: "client.transport.ignore_cluster_name": true "client.transport.nodes_sampler_interval": "5s" "client.transport.ping_timeout": "5s" "client.transport.sniff": false # XXX : notice here repositories.enabled: false 

Voir ce

Je suppose que vous configurez le serveur ES sur un hôte distant? Dans ce cas, vous devrez associer l’adresse de publication à l’adresse IP publique de l’hôte.

Dans votre hôte ES, éditez /etc/elasticsearch/elasticsearch.yml et ajoutez son adresse IP publique après network.publish_host:

 # Set the address other nodes will use to communicate with this node. If not # set, it is automatically derived. It must point to an actual IP address. # network.publish_host: 192.168.0.1 

Et dans votre code, connectez-vous à cet hôte sur le port 9300. Notez que vous avez besoin de l’adresse IP et non du nom de domaine (du moins selon mon expérience sur Amazon EC2).

Si vous rencontrez toujours des problèmes, même si vous utilisez le port 9300, et que tout le rest semble être configuré correctement, essayez d’utiliser une version plus ancienne de elasticsearch.

La même erreur se produisait lorsque j’utilisais elasticsearch version 2.2.0, mais dès que je suis revenu à la version 1.7.5, mon problème a disparu comme par magie. Voici un lien vers une autre personne ayant ce problème: l’ ancienne version résout le problème

Pour les personnes ayant des problèmes similaires, j’ai reçu ce cluster.name car je n’avais pas défini cluster.name dans le générateur TransportClient . Ajout de la propriété et tout a fonctionné.

Une autre raison pourrait être que votre client Java Elasticsearch est une version différente de votre serveur Elasticsearch .

La version du client Java Elasticsearch n’est que la version de votre fichier jarre elasticsearch dans votre base de code.

Par exemple: Dans mon code c’est elasticsearch-2.4.0.jar

Pour vérifier la version du serveur Elasticsearch,

 $ /Users/kkolipaka/elasticsearch/bin/elasticsearch -version Version: 5.2.2, Build: f9d9b74/2017-02-24T17:26:45.835Z, JVM: 1.8.0_111 

Comme vous pouvez le constater, j’ai téléchargé la dernière version d’Elastic Server 5.2.2 mais j’ai oublié de mettre à jour le client ES Java API version 2.4.0 https://www.elastic.co/guide/fr/elasticsearch/client/java- api / current / client.html

Une autre solution consiste à inclure io.netty.netty-all dans les dépendances de projet de manière explicite.

Dans addTransportAddresses une méthode nodesSampler.sample() est en cours d’exécution et les adresses ajoutées sont en cours de vérification de leur disponibilité. Dans mon cas, le bloc try-catch avale ConnectTransportException car une méthode io.netty.channel.DefaultChannelId.newInstance() est introuvable. Le noeud ajouté n’est donc pas traité comme disponible.