# Weird shard allocation behavior when applying settings via java client **URL:** \ **Category:** Elasticsearch\ **Created:** [October 30, 2015, 11:06am UTC](https://discuss.elastic.co/t/weird-shard-allocation-behavior-when-applying-settings-via-java-client/33360 "2015-10-30T11:06:08Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![John\_D\_Ament](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/john_d_ament/32/764_2.png) [@John\_D\_Ament](https://discuss.elastic.co/u/John_D_Ament)\ **Post date:** [October 30, 2015, 11:06am UTC](https://discuss.elastic.co/t/weird-shard-allocation-behavior-when-applying-settings-via-java-client/33360/1 "2015-10-30T11:06:08Z")
ElasticSearch 1.5.2 My app dynamically applies settings to the ES cluster on start up. Before making these changes, it had been waiting on green status of the cluster before applying settings. We switched to waiting for yellow, were still seeing good results. However, in one of our environments we started seeing 1-2 primary shards not being allocated. After switching the code back to look for green status, this allocation issue went away. We switched to yellow for performance reasons, it can taken up to 30s for all of the shards to be allocated. So I'm wondering, is this expected behavior? ---
**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:** [October 31, 2015, 11:16pm UTC](https://discuss.elastic.co/t/weird-shard-allocation-behavior-when-applying-settings-via-java-client/33360/2 "2015-10-31T23:16:27Z")
If they are empty shards, then yes that is a little slow. What do the master logs show? ---
**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:41pm UTC](https://discuss.elastic.co/t/weird-shard-allocation-behavior-when-applying-settings-via-java-client/33360/3 "2017-07-05T23:41:30Z")
Closed on July 5, 2017, 11:41pm UTC