# Cluster is not available and http request failed, but request by transport client worked well

**URL:** <https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722>\
**Category:** Elasticsearch\
**Created:** [November 26, 2020, 1:27am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722 "2020-11-26T01:27:15Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![fanwang](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@fanwang](https://discuss.elastic.co/u/fanwang)\
**Post date:** [November 26, 2020, 1:27am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722/1 "2020-11-26T01:27:15Z")

</div>

**Elasticsearch version**  
V5.6.12

**JVM version**  
JDK 1.8  
**OS version**  
CentOS7.6

**Description of the problem including expected versus actual behavior** :

1. In a cluster with 3 master nodes, minuimum\_master\_nodes is 2. Kill 2 of them, keep the cluster in a not-enough-master state.
2. Send the http request, such as, curl [http://localhost:9200/\_cat/nodes](http://localhost:9200/_cat/nodes), and the request is not responsed, It's ok. But, if I send a request in this way, no exception or error was found.

```auto
TransportClient client = new PreBuiltTransportClient(Settings.EMPTY).addTransportAddress(new InetSocketTransportAddress(InetAddress.getByName("host1"), 9300))

SearchResponse response = client.prepareSearch(index).setTypes(type).setSize(1000).setQuery(queryBuilder).execute().actionGet();

```

1. I expected an expection, but it worked well.

Any help will be appreciated， thanks.

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [November 26, 2020, 5:39am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722/2 "2020-11-26T05:39:32Z")

</div>

It looks to me like the two requests are not identical. The search request should return even if no master is present while the other request requires access to information the master holds and will fail. Send the same request through the two clients and compare results.

---

<div class="post-metadata">

**Author:** ![fanwang](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@fanwang](https://discuss.elastic.co/u/fanwang)\
**Post date:** [November 26, 2020, 6:05am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722/3 "2020-11-26T06:05:46Z")

</div>

Are the two requests you mentioned sent by the same client, such as http client or transport client？It makes me confused, do you know how it happened? Thanks.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [November 26, 2020, 8:43am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722/4 "2020-11-26T08:43:26Z")

</div>

You are running a very old version, long past the [end of its supported life](https://www.elastic.co/support/eol), and should upgrade as a matter of urgency.

This behaviour is what I'd expect from reading the [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/modules-discovery-zen.html#no-master-block): by default if there's no master then searches work but admin requests don't. The difference in client is irrelevant.

**edit** sorry actually on closer inspection the docs suggest that admin requests would work in this state. I don't think that's true, at least not for something like `GET _cat/nodes`, although `GET _cat/nodes/_local` probably would.

---

<div class="post-metadata">

**Author:** ![fanwang](https://avatars.discourse-cdn.com/v4/letter/f/f4b2a3/32.png) [@fanwang](https://discuss.elastic.co/u/fanwang)\
**Post date:** [November 26, 2020, 10:51am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722/5 "2020-11-26T10:51:56Z")

</div>

Thanks , I had to choose the version for some reasons. And, I took a inspection at the [docs](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/modules-discovery-zen.html#no-master-block), the setting, discovery.zen.no\_master\_block, is the key point. But I thought there may be some wrong descriptions in the docs.

> The discovery.zen.no\_master\_block setting has two valid options:  
> all  
> All operations on the node—​i.e. both read & writes—​will be rejected. This also applies for api cluster state read or write operations, like the get index settings, put mapping and cluster state api.  
> (default)  
> Write operations will be rejected. Read operations will succeed, based on the last known cluster configuration. This may result in partial reads of stale data as this node may be isolated from the rest of the cluster.

According to my test, all of these read requests were rejected in the state. Such as,  
`POST index/type -d '{"query": {"match_all"：{}}}'`  
`GET _cat/nodes`  
`GET _cat/nodes/_local`

Did I ignore something important?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 24, 2020, 10:52am UTC](https://discuss.elastic.co/t/cluster-is-not-available-and-http-request-failed-but-request-by-transport-client-worked-well/256722/6 "2020-12-24T10:52:01Z")

</div>

Closed on December 24, 2020, 10:52am UTC

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
