# ClusterBlockException occurred when node comes back to Cluster **URL:** \ **Category:** Elasticsearch\ **Created:** [May 21, 2015, 1:34am UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052 "2015-05-21T01:34:41Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![ranzez](https://avatars.discourse-cdn.com/v4/letter/r/ecd19e/32.png) [@ranzez](https://discuss.elastic.co/u/ranzez)\ **Post date:** [May 21, 2015, 1:34am UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/1 "2015-05-21T01:34:41Z")
I was running resiliency tests for Elasticsearch and found that when Master or Data node recovers after being killed, my client library throws `org.elasticsearch.cluster.block.ClusterBlockException: blocked by: [SERVICE_UNAVAILABLE/1/state not recovered / initialized];` up to a second after recovery. It seems for me that client tries to send request to not fully recovered node, which causes this error. However, this does not seems to be right for me. Does anyone has such issues? **Java client** - 1.3.2 (provided by spring-data-elasticsearch:1.1.2.RELEASE) **Elasticsearch** - 1.5 It might be an issue with old 1.3.2 client. Is there any way to track change list of Client releases? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 21, 2015, 4:40am UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/2 "2015-05-21T04:40:54Z")
That means the node has not (re)joined the cluster, you need to give it a bit more time. ---
**Author:** ![ranzez](https://avatars.discourse-cdn.com/v4/letter/r/ecd19e/32.png) [@ranzez](https://discuss.elastic.co/u/ranzez)\ **Post date:** [May 21, 2015, 4:52pm UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/3 "2015-05-21T16:52:05Z")
That makes sense, but basically that means that my requests will be lost under traffic when the node comes up. Isn't it a Master node decision when node is ready for processing requests? Why it includes it in availability pool when it is not ready? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 21, 2015, 10:13pm UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/4 "2015-05-21T22:13:04Z")
How do you know it's part of the cluster though? Have you checked another active node in the cluster and can see it's listed? ---
**Author:** ![ranzez](https://avatars.discourse-cdn.com/v4/letter/r/ecd19e/32.png) [@ranzez](https://discuss.elastic.co/u/ranzez)\ **Post date:** [May 21, 2015, 11:15pm UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/5 "2015-05-21T23:15:36Z")
Let me explain usecase in details: 1. Start ES cluster with several nodes 2. Start loading ES using client App 3. Drop (kill) one of ES nodes. 4. Continue loading 5. Start dropped ES node an let it become a part of cluster -\> during this process I experience mentioned exception. That basicaly means for me, that ES node is available to handle requests from client perspective, but it is not ready. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 24, 2015, 2:00am UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/6 "2015-05-24T02:00:01Z")
There is a difference between the service being started, the client running and the node actually ready to push data to the cluster though. ---
**Author:** ![ranzez](https://avatars.discourse-cdn.com/v4/letter/r/ecd19e/32.png) [@ranzez](https://discuss.elastic.co/u/ranzez)\ **Post date:** [May 24, 2015, 2:42am UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/7 "2015-05-24T02:42:02Z")
So, how can I fix it? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 24, 2015, 11:26pm UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/8 "2015-05-24T23:26:51Z")
Check the logs to see when the node actually joins the cluster, otherwise query the `_cat/nodes` endpoint via a different node for the same thing. ---
**Author:** ![ranzez](https://avatars.discourse-cdn.com/v4/letter/r/ecd19e/32.png) [@ranzez](https://discuss.elastic.co/u/ranzez)\ **Post date:** [July 25, 2015, 7:47pm UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/9 "2015-07-25T19:47:38Z")
So essentially there's no other way then retry ClusterBlockException in client code to other node. ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [July 26, 2015, 4:29am UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/10 "2015-07-26T04:29:36Z")
Yeah, but there is this [https://github.com/elastic/elasticsearch/issues/11709](https://github.com/elastic/elasticsearch/issues/11709) ---
**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, 11:58pm UTC](https://discuss.elastic.co/t/clusterblockexception-occurred-when-node-comes-back-to-cluster/1052/11 "2017-07-05T23:58:57Z")