Examine work performed on Hystrix-isolated thread

[mattrjacobs]

From #327 and #378, the Execution hook onThreadComplete is getting called earlier than in Hystrix 1.3. This issue is intended to describe the differences between what work gets executed on the isolated thread in 1.3 and 1.4 and confirm this is being done properly

[mattrjacobs]

HystrixCommand

Semaphore isolation

1. If the command is semaphore-isolated and invoked via execute()/queue(), then everything happens on the calling thread.
2. If the command is semaphore-isolated and invoked via observe(), then everything happens on the calling thread as well. There is also the possibilty of a non-blocking timeout, which is not yet implemented and will come with issue 1.4: executionTimeout property for async #300. That timeout mechanism should run on the HystrixTimer thread.

Thread isolation

1. If the command is thread-isolated, and the command actually reaches the run() method, then all work after that point runs on the Hystrix thread.
2. A corollary to 1, if the command gets rejected by the thread-pool, the fallback and bookkeeping work happen on the calling thread.
3. An exception to 1, if a timeout occurs on a thread-isolated command accessed via execute()/queue(), then the fallback/bookkeeping work happens on the calling thread.
4. Same as 3 but invoked via observe(). In this case, the calling thread is kept unscheduled and the fallback/bookkeeping work in done on a HystrixTimer thread.

All of this fits with the work done above, which moved the onThreadComplete event further back in the chain.

HystrixObservableCommand

Note that only the observe() method is available on HystrixObservableCommand.

Semaphore isolation

1. If the command is semaphore-isolated and invoked via observe(), then setup and command execution happen on the calling thread. As construct() may do its work on another thread, all fallback and bookkeeping work will get chained onto that thread.
2. If the command times out, then the HystrixTimer thread runs the timeout logic and fallback. Note that the resumeWithFallback() method may use a different thread. If it does, the remainder of the bookkeeping will work on that thread.

Thread isolation

1. If the command is thread-isolated, then all setup occurs on the calling thread. The construct() method is run on the Hystrix thread. If successful, then all further work is chained onto the computation within construct(). So if construct() does not utilize another thread, the bookkeeping happens on the Hystrix thread. On the other hand, if construct() uses an RxComputation thread via observeOn(), then the actual work and bookkeeping all happens on that thread.
2. If the command fails, then the fallback is chained onto whatever thread was running the work in construct(). As the resumeWithFallback() method may do its work on a new thread, all bookkeeping work gets chained onto that thread.
3. In the case of a timeout, then the timeout logic and fallback execution occur on the HystrixTimer. As the resumeWithFallback() method may do its work on a new thread, all bookkeeping work gets chained onto that thread.

[mattrjacobs]

/cc @benjchristensen @KoltonAndrus to see if this fits your expectations/intuitions

[benjchristensen]

Same as 3 but invoked via observe(). In this case, the calling thread is kept unscheduled and the fallback/bookkeeping work in done on a HystrixTimer thread.

Is this the case for a HystrixCommand? That is synchronous so that shouldn't have an async timeout. The most that could be done is interrupt the thread ... which would be the calling thread.

[benjchristensen]

This all sounds correct except for my previous question.