We have three nodes cluster on EC2 and in the pre-production phase we
need to interface with the cluster from our local network.
Unfortunately, we frequently get NoNodeAvailableException (we use JAVA
API). I have dug the group and tried almost everything and yes I am
sure we are using the same version of ES and at the moment we cannot
upgrade from 0.18.7 to 0.19.0 (the latest version at the time of
writing this down)
In order to fix this issue I want to create a service wrapper around
transport client to do health check prior to any queries to the
cluster. If the health check did not pass I have to reacquire the
cluster. But I foresee a problem! What would happen to the in progress
calls (the ones that were made and not returned prior to getting
NoNodeAvailableException! -- this could happen if you have a web-app
making tons of calls to ES through JAVA API)? Do they really matter? I
mean if NoNodeAvailableException is caught they would also go bad (I
am almost sure but need a nod for it)?
We have three nodes cluster on EC2 and in the pre-production phase we
need to interface with the cluster from our local network.
Unfortunately, we frequently get NoNodeAvailableException (we use JAVA
API). I have dug the group and tried almost everything and yes I am
sure we are using the same version of ES and at the moment we cannot
upgrade from 0.18.7 to 0.19.0 (the latest version at the time of
writing this down)
In order to fix this issue I want to create a service wrapper around
transport client to do health check prior to any queries to the
cluster. If the health check did not pass I have to reacquire the
cluster. But I foresee a problem! What would happen to the in progress
calls (the ones that were made and not returned prior to getting
NoNodeAvailableException! -- this could happen if you have a web-app
making tons of calls to ES through JAVA API)? Do they really matter? I
mean if NoNodeAvailableException is caught they would also go bad (I
am almost sure but need a nod for it)?
the most common case for NoNodeAvailable is the regular pinging that the transport client does fails to do it, so no nodes end up as the list of nodes that the transport client uses. If you will set client.transport (or org.elasticsearch.client.transport if running embedded) to TRACE, you will see the pinging effort and if it failed or not (and the reason for the failures). This might get us further into trying to understand why it happens.
On Tuesday, March 6, 2012 at 10:41 PM, Ali Loghmani wrote:
We have three nodes cluster on EC2 and in the pre-production phase we
need to interface with the cluster from our local network.
Unfortunately, we frequently get NoNodeAvailableException (we use JAVA
API). I have dug the group and tried almost everything and yes I am
sure we are using the same version of ES and at the moment we cannot
upgrade from 0.18.7 to 0.19.0 (the latest version at the time of
writing this down)
In order to fix this issue I want to create a service wrapper around
transport client to do health check prior to any queries to the
cluster. If the health check did not pass I have to reacquire the
cluster. But I foresee a problem! What would happen to the in progress
calls (the ones that were made and not returned prior to getting
NoNodeAvailableException! -- this could happen if you have a web-app
making tons of calls to ES through JAVA API)? Do they really matter? I
mean if NoNodeAvailableException is caught they would also go bad (I
am almost sure but need a nod for it)?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.