¿Por qué ZUUL está forzando un aislamiento SEMAPHORE para ejecutar sus comandos Hystrix?

Noté que Spring-Cloud ZUUL fuerza el aislamiento de ejecución a SEMAPHORE en lugar de los valores predeterminados de THREAD (como lo recomienda Netflix).

Un comentario enorg.springframework.cloud.netflix.zuul.filters.route.RibbonCommand dice:

queremos usar el aislamiento de semáforo por defecto ya que esto envuelve otros 2 comandos que ya están aislados en subprocesos

Pero aún así no lo entiendo :-( ¿Cuáles son esos otros dos comandos?

Configurado de esta manera, Zuul solo puede programar la carga, pero no permite el tiempo de espera y deja que el cliente se vaya. En resumen, incluso si el tiempo de espera de Hystrix se establece en 1000 ms, los clientes solo se liberarán una vez que la llamada reenviada al servicio en la cadena regrese (o los tiempos de espera debido a un ReadTimeout, por ejemplo).

Intenté forzar el aislamiento de THREAD anulando la configuración (desafortunadamente por servicio, ya que el código predeterminado es forzado) y todo parece funcionar como se esperaba. Sin embargo, no estoy interesado en hacer esto sin una comprensión adecuada de las implicaciones, ciertamente en lo que respecta al comentario encontrado en el código y los valores predeterminados adoptados por la versión Spring Cloud de Zuul.

¿Alguien puede proporcionar más información? Gracias

Respuestas a la pregunta(2)

Su respuesta a la pregunta