Isolation Strategy with Async library

[esrishi]

Hi All,
We already use HttpAsync in some libraries that I plan to incorporate hystrix. I know THREAD isolation strategy is recommend for network calls, but if we already are using Async library to make the network call which provides Future and transaction level timeout capability is SEMAPHORE a better isolation strategy. Thoughts?

To add on, as mentioned in #862 to prevent overload of Threadpools is SEMAPHORE an option even for blocking http calls.

Thanks,
Rishi.

[mattrjacobs]

For calls which are already async, you should use HystrixObservableCommand. Using HystrixCommand dictates returning a T from your run() method, where HystrixObservableCommand dictates returning a Observable from your construct() method.

So to fulfill HystrixCommand, you have to either block somewhere on the return of your async call, or return the async handle. If you just return the async handle, you've lost the ability to monitor how many async tasks are in flight (which is one of the prime benefits of using Hystrix).

So if you want to avoid blocking, you should use HystrixObservableCommand. And in that case, you should be using semaphore isolation.

[esrishi]

Hi @mattrjacobs, I agree returning the async handler would defeat the benefits provided by hystrix.

What I meant was, if I know an existing client library is already using HttpAsync to return a response object(not the async handler), using semaphore isolation strategy will avoid additional threads from getting created in the app.
And if this can be an option even in case of blocking I/O call, in case of large number of nodes.

If using semaphore isolation strategy, do you lose some of thread pool capabilities like -transaction timeout (for blocking I/O), queue size and rejection threshold.

[mattrjacobs]

If you trust the HTTP library to properly return threads to your application, then semaphores may be used. In that scenario, you will get load-shedding/fast-fails when the service backed by your HystrixCommand goes latent, and application threads that are in the execution within the semaphore will be subject to the behavior of the HTTP lib.

The benefit of a thread-pool over this approach is that Hystrix explicitly guarantees that the application thread will walk away in these circumstances. If your library already does that, then you're set.

[esrishi]

Thanks @mattrjacobs for clarifying the underlying behaviour.