CODEWITHSUNDEEP
spring-cloudhystrixcircuit-breaker
Shivraj
Shivraj

Reputation: 492

Spring Cloud Circuit Breakers or Hystrix

Hystrix is predominantly meant for applications built using spring cloud. Having said that there could be multiple services layer for an application.

e.g. Amazon (Amazon site must be having multiple services like login, products, carts, orders, payment and so on)

Client (say web user) -> web application X -> Service A (it uses Data Source A ) -> Service B (Data Source B) -> Service C (Data Source C) -> Service D (Data Source D) -> Service E (Data Source E)

with this kind of scenario when something breaks in Service E, How that gets navigated back to client? How Hystrix can be useful here to know unavailability of one specific functionality in Service E?

If that example is wrong, then is Hystrix scope limited to multiple processes inside one service and not multiple services used in one application? Having said that above example can be tweaked something like below

Client (say web user) -> web application X -> Service A -> inside Service A Lets say there are processes like process 1 ->process 2 ->process 3 ->process 4->process 5 and anything fails in process 5 gets navigated back to process 1 and then back to client.

My question is more about maintaining thread state here.

With try-catch thread scope is limited per service (please correct me if wrong).

How Hystrix maintains state of thread during this whole transaction?

Upvotes: 2

Views: 694

Answers (1)

pvpkiran
pvpkiran

Reputation: 27048

Hystrix is predominantly meant for applications built using spring cloud

Not exactly. Hystrix is generally used to enable Circuit Breaker functionality. It could be used everywhere. Even for a simple method call For example

class A {

    B b;

    public void methodA() {
               b.methodB();
    }
}


class A {

    DatabaseConnectionPool object;


    @HystrixCommand(fallbackMethod = "abcd")
    public void methodB() {
               // Get db object from pool. 
               // call db and fetch something.
    }
}

Even for a simple method call, it can be used. Doesn't matter what is being done inside the code wrapped around Hystrix. But generally we use Hystrix around pieces of code which would throw exceptions for unknown reasons (especially when calling differnt applications)

with this kind of scenario when something breaks in Service E, How that gets navigated back to client? How Hystrix can be useful here to know unavailability of one specific functionality in Service E?

If you wrap each method call i.e from Service A --> Service B and Service B --> Service C and further with Hystrix, then each call is treated as a circuit and you can visualize using Hystrix-dashboard, what is the state(closed, open, half-open) of each circuit. Let's assume the call from Service B --> Service C fails(throws exception) then Hystrix would wrap the original exception in Hystrix Exception and throws it back. If you have a fallback method, then it goes to the fallback method in Service B and returns the value specified in fallback. If you don't have fallback then it throws the exception higher up the chain. And same thing repeats higher up the chain.

How Hystrix maintains state of thread during this whole transaction ?

For each call wrapped with Hystrix, Hystrix maintains a Thread Pool and you can configure this completely.

If I already have an existing Java feature of using try-catch why will someone go for Hystrix explicitly?

Hystrix provides much more functionality. You cannot even compare that with try catch. I suggest you read Circuit breaker pattern.

Upvotes: 2

Related Questions