NoNodeAvailableException

Elastic Stack Elasticsearch
1

Version 0.19.4.

We are getting this exception occasionally, on the client that is
performing searches. There is no indexing going on at this time.

Having read through the previous messages, the first thing was to turn on
debug logging for org.elasticsearch.client.transport. I did that, but am
not seeing any messages in the log file pertaining to the error. I am
getting these messages in my log file, so I'm sure I have debug logging
turned on.

DEBUG 18:27:33 [transport:94] [Devil-Slayer] node_sampler_interval[5s]

DEBUG 18:27:33 [transport:94] [Devil-Slayer] adding address
[[#transport#-1][inet[localhost/127.0.0.1:9300]]]

What would cause this error, but not write to the log? Any help or pointers
are appreciated. I'm a newbie with ES.

--

2

Are you running ES node and your client on the same machine?
Is your client application create a new node (and client) at each search?

I don't understand your setup.

David :wink:
Twitter : @dadoonet / @elasticsearchfr

Le 17 août 2012 à 02:43, scott scott@tempo.ai a écrit :

Version 0.19.4.

We are getting this exception occasionally, on the client that is performing searches. There is no indexing going on at this time.

Having read through the previous messages, the first thing was to turn on debug logging for org.elasticsearch.client.transport. I did that, but am not seeing any messages in the log file pertaining to the error. I am getting these messages in my log file, so I'm sure I have debug logging turned on.

DEBUG 18:27:33 [transport:94] [Devil-Slayer] node_sampler_interval[5s]

DEBUG 18:27:33 [transport:94] [Devil-Slayer] adding address [[#transport#-1][inet[localhost/127.0.0.1:9300]]]

What would cause this error, but not write to the log? Any help or pointers are appreciated. I'm a newbie with ES.

--

--

3

Server and client are on different machines.

Client creates a TransportClient once and the same TransportClient gets
reused for the lifetime of the client application.

We currently have up to 10 different threads executing searches against the
same TransportClient.

--

4

So your error comes when you restart your client application?

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 17 août 2012 à 03:58, scott scott@tempo.ai a écrit :

Server and client are on different machines.

Client creates a TransportClient once and the same TransportClient gets reused for the lifetime of the client application.

We currently have up to 10 different threads executing searches against the same TransportClient.

--

5

I reread my original post and understand your confusion. The log file
entries I copied were from a unit test and that does run on one machine.
However, we only have the issue when we push to our test environment,
which puts the server and client on separate machines.

Sorry.

--

6

No, the app starts fine and runs several successful queries. The error
happens occasionally. Not all the time.

I bumped the client.transport.ping_timeout to 10 seconds, but we are still
occasionally seeing the errors.

--

7

Ok. That means that you never succeed in connecting your client and your node in your test env?

If so, check your firewall settings (open 9300 port).

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 17 août 2012 à 04:02, scott scott@tempo.ai a écrit :

I reread my original post and understand your confusion. The log file entries I copied were from a unit test and that does run on one machine. However, we only have the issue when we push to our test environment, which puts the server and client on separate machines.

Sorry.

--

--

8

Try to update to 0.19.8 as there are some issues about nodes fixed in 0.19.5 although I don't think you get the same issue.

--
David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 17 août 2012 à 04:07, scott scott@tempo.ai a écrit :

No, the app starts fine and runs several successful queries. The error happens occasionally. Not all the time.

I bumped the client.transport.ping_timeout to 10 seconds, but we are still occasionally seeing the errors.

--

--