# Executing a custom allocation decider before an ES allocation decider **URL:** \ **Category:** Elasticsearch\ **Created:** [September 18, 2019, 5:27pm UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061 "2019-09-18T17:27:36Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![UDixit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/udixit/32/53219_2.png) [@UDixit](https://discuss.elastic.co/u/UDixit)\ **Post date:** [September 18, 2019, 5:27pm UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/1 "2019-09-18T17:27:36Z")
The `createAllocationDeciders` API in ClusterModule.cs instantiates multiple ES deciders as well as custom allocation deciders. Since these are added to a linkedHashMap, they are always executed in order. How can I ensure that my custom allocation decider executes before an ES defined allocation decider? ---
**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:** [September 18, 2019, 5:50pm UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/2 "2019-09-18T17:50:20Z")
The order of allocation deciders shouldn't matter, because the final decision is the minimum of the decisions from each decider (where `NO < THROTTLE < YES`). Can you explain why the order is important to you? ---
**Author:** ![UDixit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/udixit/32/53219_2.png) [@UDixit](https://discuss.elastic.co/u/UDixit)\ **Post date:** [September 18, 2019, 7:45pm UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/3 "2019-09-18T19:45:56Z")
From the code, it looks like, you call the `AllocationDeciders.canAllocate()` API. The`AllocationDeciders` is a composite of multiple decisions. It does help short track if a `NO` decision is made. In my case, I am trying to minimize the number of calls to allocationDeciders. Since my custom decider will filter out a lot of ineligible nodes, I want to call it before the AwarenessDecider. ---
**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:** [September 18, 2019, 8:39pm UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/4 "2019-09-18T20:39:11Z")
I see, yes, a `NO` does short-circuit the later deciders. I'm a bit surprised that the awareness decider is expensive enough to need it, however. Do you know why it's slow? Also, what is the decider you're implementing? Maybe we could run the existing deciders in a better order instead? ---
**Author:** ![UDixit](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/udixit/32/53219_2.png) [@UDixit](https://discuss.elastic.co/u/UDixit)\ **Post date:** [September 18, 2019, 9:48pm UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/5 "2019-09-18T21:48:59Z")
I am working on a very large cluster and want to efficiently filter out nodes which are ineligible for allocation. The nodes in the cluster have 4-5 attributes. I am already EnableAllocationDecider and FilterAllocationDecider and ShardsLimitAllocationDecider but I also have my custom allocation decider to drastically reduce the number of eligible nodes.(it used the number of partitions in an index) I want to call awareness decider after all the above allocators have run to ensure equal distribution across AvailabilityZones. ---
**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:** [September 20, 2019, 5:17am UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/6 "2019-09-20T05:17:04Z")
I cannot see an easy way to do this from a plugin, sorry. I'd still like to understand in more detail why the awareness decider is a bottleneck for you, because maybe there are things we can do to improve its performance. Can you share a test (e.g. an `ESAllocationTestCase`) that shows a case where it is too slow for you? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [October 18, 2019, 5:17am UTC](https://discuss.elastic.co/t/executing-a-custom-allocation-decider-before-an-es-allocation-decider/200061/7 "2019-10-18T05:17:18Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.