# Cannot set thread\_pool setting in Elastic Cloud user settings

**URL:** <https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239>\
**Category:** Elasticsearch\
**Created:** [January 15, 2019, 5:43am UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239 "2019-01-15T05:43:06Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![CapitanRedBeard](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/capitanredbeard/32/33034_2.png) [@CapitanRedBeard](https://discuss.elastic.co/u/CapitanRedBeard)\
**Post date:** [January 15, 2019, 5:43am UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239/1 "2019-01-15T05:43:06Z")

</div>

Using ES `v6.4.3`

I'm getting a bunch of TransportService errors when writing a high volume of transactions. The exact error is:

```auto
StatusCodeError: 429 - {"error":{"root_cause":[{"type":"remote_transport_exception","reason":"[instance-0000000002][10.44.0.71:19428][indices:data/write/bulk[s][p]]"}],"type":"es_rejected_execution_exception","reason":"rejected execution of org.elasticsearch.transport.TransportService$7@35110df8 on EsThreadPoolExecutor[name = instance-0000000002/write, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@3fd60b4f[Running, pool size = 2, active threads = 2, queued tasks = 200, completed tasks = 1705133]]"},"status":429}

```

The general consensus seems to be bumping the queue\_size so requests don't get dropped. As you can see in the error my queue\_size is the default 200, and filled up. (I know simple bumping the queue\_size is not a magic solution, but this is exactly what I need in this case)

So following [this doc](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-add-user-settings.html#ece-add-user-settings) on how to change the elasticsearch.yml setting I try to add the queue\_size bump here:

![42%20PM](https://us1.discourse-cdn.com/elastic/original/3X/e/7/e721d5a0743bc7dd71b45d7ba18d8f501de49a1c.png)

```auto
thread_pool.write.queue_size: 2000

```

And when I save I get this error:

 ![48%20PM](https://us1.discourse-cdn.com/elastic/original/3X/8/c/8cdcaec365129ed0bad9acdb2131d63709c6d637.png)

```auto
'thread_pool.write.queue_size': is not allowed

```

I understand the user override settings blacklist certain settings, so if my problem is truly that `thread_pool.write.queue_size` is blacklisted, how can I access my elasticsearch.yml file to change it?

Thank you!

---

<div class="post-metadata">

**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:** [January 15, 2019, 5:48am UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239/2 "2019-01-15T05:48:02Z")

</div>

> [@CapitanRedBeard](#):
>
> The general consensus seems to be bumping the queue\_size so requests don't get dropped

Dunno where you are getting that consensus from, but I would be confident in saying that it's not the best idea. Have a read of [Any idea what these errors mean version 2.4.2 - #5 by jasontedor](https://discuss.elastic.co/t/any-idea-what-these-errors-mean-version-2-4-2/70690/5)

If you are using the Elasticsearch Service then you can increase the size of the cluster when you are sending these requests, then downsize when done.  
Or you can throttle things in your client when you get a 429.

---

<div class="post-metadata">

**Author:** ![CapitanRedBeard](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/capitanredbeard/32/33034_2.png) [@CapitanRedBeard](https://discuss.elastic.co/u/CapitanRedBeard)\
**Post date:** [January 15, 2019, 5:53am UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239/3 "2019-01-15T05:53:40Z")

</div>

Hey thanks mark, yeah I've read that post on a couple other issue pages. I understand that just increasing size is not the complete solution because it does not address the root of the problem. For my specific situation I'm trying to migrate a large volume of data as quickly as possible so my preference is to bump up queue size while I complete my migration script then reset it back to what it was so my client can operate within its limits.

That being said, do you know I can access the proper elasticsearch.yml file, or is the user setting override the correct one and I'm not using the correct setting?

Thanks!

---

<div class="post-metadata">

**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:** [January 15, 2019, 9:14am UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239/4 "2019-01-15T09:14:48Z")

</div>

You can see what settings you can alter right here - [https://www.elastic.co/guide/en/cloud/current/ec-add-user-settings.html#ec-es-elasticsearch-settings](https://www.elastic.co/guide/en/cloud/current/ec-add-user-settings.html#ec-es-elasticsearch-settings)

If it's not listed, it's not alterable.

---

<div class="post-metadata">

**Author:** ![CapitanRedBeard](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/capitanredbeard/32/33034_2.png) [@CapitanRedBeard](https://discuss.elastic.co/u/CapitanRedBeard)\
**Post date:** [January 15, 2019, 4:29pm UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239/5 "2019-01-15T16:29:04Z")

</div>

Okay thanks Mark

---

<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:** [February 12, 2019, 4:29pm UTC](https://discuss.elastic.co/t/cannot-set-thread-pool-setting-in-elastic-cloud-user-settings/164239/6 "2019-02-12T16:29:05Z")

</div>

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