# Contradictory and, sometimes, poor, advice given for es.set.netty.runtime.available.processors

**URL:** <https://discuss.elastic.co/t/contradictory-and-sometimes-poor-advice-given-for-es-set-netty-runtime-available-processors/148014>\
**Category:** Elasticsearch\
**Created:** [September 10, 2018, 7:55pm UTC](https://discuss.elastic.co/t/contradictory-and-sometimes-poor-advice-given-for-es-set-netty-runtime-available-processors/148014 "2018-09-10T19:55:09Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Stu\_S](https://avatars.discourse-cdn.com/v4/letter/s/dbc845/32.png) [@Stu\_S](https://discuss.elastic.co/u/Stu_S)\
**Post date:** [September 10, 2018, 7:55pm UTC](https://discuss.elastic.co/t/contradictory-and-sometimes-poor-advice-given-for-es-set-netty-runtime-available-processors/148014/1 "2018-09-10T19:55:09Z")

</div>

Elasticsearch has a setting "processors" that defaults to "Runtime.getRuntime().availableProcessors()":

> <https://github.com/elastic/elasticsearch/blob/462e91d362c9ce8aa807a702081f9bbd76f8d019/server/src/main/java/org/elasticsearch/common/util/concurrent/EsExecutors.java>

It takes that setting, and tries to set the availableProcessor variable in Netty:

> <https://github.com/elastic/elasticsearch/blob/b697f485bb4815b231f4accb5725fdc237214aef/modules/transport-netty4/src/main/java/org/elasticsearch/transport/netty4/Netty4Utils.java#L79>

Unless a particular system property is set:

> <https://github.com/elastic/elasticsearch/blob/b697f485bb4815b231f4accb5725fdc237214aef/modules/transport-netty4/src/main/java/org/elasticsearch/transport/netty4/Netty4Utils.java#L69>

Netty throws an IllegalStateException if that method is called twice:

[https://netty.io/4.0/api/io/netty/util/NettyRuntime.html#setAvailableProcessors-int-](https://netty.io/4.0/api/io/netty/util/NettyRuntime.html#setAvailableProcessors-int-)

Elasticsearch does not catch that exception, and fails to initialize if the exception is thrown.

However, it initializes _just fine_ if you set the system property that tells it not to bother invoking the Netty call.

Which means, if any other library in your application uses Netty, and calls that method, and then Elasticsearch calls that method, your application will either:

- crash
- not have a valid Elasticsearch connection

The advice, given by Elasticsearch, in other discussion is:

> this is on application developers to know their application and either:  
> set the system property I indicated above  
> allow Elasticsearch to configure Netty first

> <https://github.com/elastic/elasticsearch/issues/25741#issuecomment-322327914>
>
> detail: https://stackoverflow.com/questions/45116826/create-elasticsearch-clien…t-throws-a-netty-illegalstateexception
> 
> The first time to \`new PreBuiltTransportClient()\` ,it throws the following exception, but the second time ,it creates \`PreBuiltTransportClient\` successfully, and this problem also happens in ElasticSearch-5.5.0:
> 
> \`
> Exception in thread "Full-Scan-Thread" java.lang.IllegalStateException: availableProcessors is already set to \[8\], rejecting \[8\]
> at io.netty.util.NettyRuntime$AvailableProcessorsHolder.setAvailableProcessors(NettyRuntime.java:51)
> at io.netty.util.NettyRuntime.setAvailableProcessors(NettyRuntime.java:87)
> at org.elasticsearch.transport.netty4.Netty4Utils.setAvailableProcessors(Netty4Utils.java:82)
> at org.elasticsearch.transport.netty4.Netty4Transport.\<init\>(Netty4Transport.java:138)
> at org.elasticsearch.transport.Netty4Plugin.lambda$getTransports$0(Netty4Plugin.java:93)
> at org.elasticsearch.client.transport.TransportClient.buildTemplate(TransportClient.java:174)
> at org.elasticsearch.client.transport.TransportClient.\<init\>(TransportClient.java:265)
> at org.elasticsearch.transport.client.PreBuiltTransportClient.\<init\>(PreBuiltTransportClient.java:130)
> at org.elasticsearch.transport.client.PreBuiltTransportClient.\<init\>(PreBuiltTransportClient.java:116)
> \`

Oh, and:

> This setting is not documented on purpose since it should never be set.

> [@Need Info for "es.set.netty.runtime.available.processors"](https://discuss.elastic.co/t/need-info-for-es-set-netty-runtime-available-processors/111322):
>
> Hi, I have upgraded Elastic search from 5.3.1 to 6.0.0. I need some documentation about "es.set.netty.runtime.available.processors" , what is the purpose, or how to use etc. I didn't find much details.

So much bad here:

- One, the recommend solution is also recommended to never be done

- Two, the onus, apparently is on users of elasticsearch to "know their application", which apparently, means, reading the code base of every dependency they use, in search of possibly conflicting calls to other dependencies, and the undocumented runtime properties that should be set to disable them.

So much bad here. It seems like a better approach would be to:

- decide whether or not the Netty availableProcessors is an important enough setting that you want elasticsearch to crash out or not
- if it's not important enough, catch the exception, and move on, issuing a warning
- if is important enough - why make a workaround where you can disable it?
- If you insist on using a system property to ignore the crashing condition, instead of just catching the exception.
- decide what is recommended
- document it

oh, the best part of all of this the default that Netty uses is _exactly the same_ as the default that elasticsearch uses. Which means that, unless you explicitly set the processor variable, all that Elasticsearch code is just crashing your app in an attempt to set a variable to a value that it's already set to ☹

---

<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:** [October 8, 2018, 7:55pm UTC](https://discuss.elastic.co/t/contradictory-and-sometimes-poor-advice-given-for-es-set-netty-runtime-available-processors/148014/2 "2018-10-08T19:55:14Z")

</div>

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