# Best timeout value for setWaitForYellowStatus **URL:** \ **Category:** Elasticsearch\ **Created:** [April 5, 2016, 6:54pm UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443 "2016-04-05T18:54:22Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Pradeep\_Gowda](https://avatars.discourse-cdn.com/v4/letter/p/ebca7d/32.png) [@Pradeep\_Gowda](https://discuss.elastic.co/u/Pradeep_Gowda)\ **Post date:** [April 5, 2016, 6:54pm UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/1 "2016-04-05T18:54:22Z")
Hey Everyone, When I upgraded my Elasticsearch to 2.3.0 from 2.2.0 and I started seeing slowness in shard allocation. So I added below code in my client to wait till the cluster turns yellow `client.admin().cluster().prepareHealth().setWaitForYellowStatus().setTimeout(TimeValue.timeValueMinutes(1)).execute().actionGet();` I have two questions. 1. What is the best way to handle this scenario. In 2.3, it took like 5 min to redistribute the shards vs 30 sec in 2.2. By default setWaitForYellowStatus waits for 30s. 2. How can I increase timeout? It looks like setTimeout is not working and it is falling back to default 30s. Regards, ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [April 12, 2016, 9:16am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/2 "2016-04-12T09:16:32Z")
Hi, I suggest you don't rely on timeout but rather poll in a loop. Consider a huge index that would take hours to recover. If you rely on timeout you'd block one of your program threads for hours. The polling approach gives you the option to apply different strategies (e.g. increasing the waiting the period between checks, asking for user input, stopping to poll after a certain timeout etc. etc.). As a rough sketch, I'd do something like this: ```java while (true) { ClusterHealthResponse clusterHealthResponse = client.admin().cluster() .prepareHealth() .setWaitForYellowStatus() .setTimeout(TimeValue.timeValueMillis(500)) .execute() .actionGet(); if (clusterHealthResponse.isTimedOut()) { //wait for 20 seconds, then retry. You can do lots of fancy // things here - just as I've described above Thread.sleep(20 * 1000); } else { // we've reached yellow status, go on break; } } ``` To your second point: I've set the timeout locally to one minute and measured the time. The request timed out after one minute, just as expected. But as I suggested above I'd rather set a shorter timeout than the default and use polling. Daniel ---
**Author:** ![Pradeep\_Gowda](https://avatars.discourse-cdn.com/v4/letter/p/ebca7d/32.png) [@Pradeep\_Gowda](https://discuss.elastic.co/u/Pradeep_Gowda)\ **Post date:** [April 13, 2016, 8:31pm UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/3 "2016-04-13T20:31:28Z")
Hi Dani, Thank you for your response. When I try to get the elastic health using above, I am getting exception as follows. ``` Exception in init thread : java.lang.IllegalStateException: ClusterService was close during health call at org.elasticsearch.action.admin.cluster.health.TransportClusterHealthAction$3.onClusterServiceClose(TransportClusterHealthAction.java:155) [elasticsearch-2.2.0.jar:2.2.0] at org.elasticsearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onClose(ClusterStateObserver.java:225) [elasticsearch-2.2.0.jar:2.2.0] at org.elasticsearch.cluster.service.InternalClusterService.doStop(InternalClusterService.java:208) [elasticsearch-2.2.0.jar:2.2.0] at org.elasticsearch.common.component.AbstractLifecycleComponent.stop(AbstractLifecycleComponent.java:88) [elasticsearch-2.2.0.jar:2.2.0] at org.elasticsearch.node.Node.stop(Node.java:300) [elasticsearch-2.2.0.jar:2.2.0] at org.elasticsearch.node.Node.close(Node.java:325) [elasticsearch-2.2.0.jar:2.2.0] at org.elasticsearch.bootstrap.Bootstrap$4.run(Bootstrap.java:157) [elasticsearch-2.2.0.jar:2.2.0] {code} ``` But when I check the elastic log, it was up and the shard allocation was under progress. ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [April 14, 2016, 4:30am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/4 "2016-04-14T04:30:15Z")
Hi, interesting. How do you connect to Elasticsearch? Do you use the node or the transport client? Daniel ---
**Author:** ![Pradeep\_Gowda](https://avatars.discourse-cdn.com/v4/letter/p/ebca7d/32.png) [@Pradeep\_Gowda](https://discuss.elastic.co/u/Pradeep_Gowda)\ **Post date:** [April 14, 2016, 4:44am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/5 "2016-04-14T04:44:12Z")
I am using Transport Client. This doesn't happen everytime though. ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [April 15, 2016, 8:00am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/6 "2016-04-15T08:00:55Z")
Does this also happen with the default timeout? Because the only thing that has changed was the timeout and that you repeat the calls now on timeout. ---
**Author:** ![Pradeep\_Gowda](https://avatars.discourse-cdn.com/v4/letter/p/ebca7d/32.png) [@Pradeep\_Gowda](https://discuss.elastic.co/u/Pradeep_Gowda)\ **Post date:** [April 15, 2016, 8:16pm UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/7 "2016-04-15T20:16:00Z")
Yes, It happens on default timeout. What may be the reason? Even though this health check is in the loop, I don't get the status at first call itself. Rather than handling this kind of issue at the client side, I feel it's better to handle at service side. ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [April 18, 2016, 7:22am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/8 "2016-04-18T07:22:52Z")
Hi, the exception trace indicates that one of your cluster nodes is about to shutdown (and others can still be up). Do you have multiple nodes in your cluster? Did you check the logs on all of them? If you mean by "service side", that it should be handled by Elasticsearch: It is perfectly fine that nodes leave and join the cluster (you may want to take down a node for maintenance). Daniel ---
**Author:** ![Pradeep\_Gowda](https://avatars.discourse-cdn.com/v4/letter/p/ebca7d/32.png) [@Pradeep\_Gowda](https://discuss.elastic.co/u/Pradeep_Gowda)\ **Post date:** [April 18, 2016, 7:53am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/10 "2016-04-18T07:53:40Z")
Yes, I have three nodes in the cluster and look's like all node's were up. ---
**Author:** ![danielmitterdorfer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/danielmitterdorfer/32/110510_2.png) [@danielmitterdorfer](https://discuss.elastic.co/u/danielmitterdorfer)\ **Post date:** [April 18, 2016, 8:47am UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/11 "2016-04-18T08:47:32Z")
Is there any exception trace in the log that indicates a problem? Can you correlate the log events on the cluster's nodes with the problem on client side? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:58pm UTC](https://discuss.elastic.co/t/best-timeout-value-for-setwaitforyellowstatus/46443/12 "2017-07-05T22:58:36Z")