Why is ZUUL forcing a SEMAPHORE isolation to execute its Hystrix commands?

Question

I noticed Spring-Cloud ZUUL forces the execution isolation to SEMAPHORE instead of the THREAD defaults (as recommended by Netflix).

A comment in org.springfram

Answer 1

This pattern is defined in the Hystrix documentation

The façade HystrixCommand can use semaphore-isolation since all of the work it is doing is going through two other HystrixCommands that are already thread-isolated. It is unnecessary to have yet another layer of threading as long as the run() method of the façade is not doing any other network calls, retry logic, or other “error prone” things.

The reason why we only use semaphore is because

1. We want to throttle number of requests to primary & secondary (may be more) combined
2. Since isolation is already achieved by the actual hystrix command thread pools (that this facade proxies), we dont need to need to worry about isolatation at this level using threadpools (each thread in the pool has a fixed overhead interms of resource consumption, unlike semaphore which is just a counter). So, lightweight semaphore is good enough

Reference: https://github.com/Netflix/Hystrix/wiki/How-To-Use#primary--secondary-with-fallback