I m trying to understand the difference between HystrixCommand and HystrixObservableCommand. The reason i am confused is the HysterixCommand also has a observe() or toObservable() method which emit hot and cold observable respectively. So what was the need to create HystrixObservableCommand. If i will be working completely on non blocking calls which one should i use? why?
Used to wrap code that will execute potentially risky functionality (typically meaning a service call over the network) with fault and latency tolerance, statistics and performance metrics capture, circuit breaker and bulkhead functionality. This command should be used for a purely non-blocking call pattern.
Interface HystrixCommandGroupKeyA group name for a HystrixCommand . This is used for grouping together commands such as for reporting, alerting, dashboards or team/library ownership. By default this will be used to define the HystrixThreadPoolKey unless a separate one is defined.
resumeWithFallback() which returns an Observable that may emit a fallback value or values. If the fallback method returns a response then Hystrix will return this response to the caller. In the case of a HystrixCommand. getFallback() , it will return an Observable that emits the value returned from the method.
The Hystrix command key is used to identify a command instance for statistics, circuit-breaker, properties, etc. String. fallbackMethod. Specifies a method to process fallback logic.
From the Javadocs:
HystrixCommand
This command is essentially a blocking command but provides an Observable facade if used with observe()
HystrixObservableCommand
This command should be used for a purely non-blocking call pattern. The caller of this command will be subscribed to the Observable returned by the run() method.
The difference is that HystrixCommand by default supports a blocking paradigm, but also provides non-blocking behavior by way of Observables via a facade, whereas HystrixObservableCommand was implemented specifically for a non-blocking setup. I'm not entirely sure why it's split into two implementations, but I would guess that the reason is because originally HystrixCommand did not support non-blocking. It was added about a year or so after the original implementation. Could have just been cleaner to write a purely non-blocking hystrix class.
If you are working with only non-blocking calls, you should likely be using HystrixObservableCommand. Ben Christensen, one of the Hystrix devs, sums it up nicely in this post:
However, if you are wrapping blocking calls, you should just stick with using HystrixCommand as that’s what it’s built for and it defaults to running everything in a separate thread. Using HystrixCommand.observe() will give you the concurrent, async composition you’re looking for.
HystrixObservableCommand is intended for wrapping around async, non-blocking Observables that don’t need extra threads.
Additionally to the answer of Nick Defazio, an implementation of HystrixObservableCommand
wrap Observables that can emit multiple items, whereas HystrixCommand
, will never emit more than one item, even when invoking observe()
or .toObservable()
which are only wrapping the single value retuned by the run()
method.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With