about half open state

[likebean]

when circuit breaker in half open status,only one request A can be execute,if the request A fail,will back to open,if success will translate to close status. my question is how to make sure no other pre requests (execute start before circuit enter half open status but finish execute after circuit enter half open status) change circuit status before the request A?

[mattrjacobs]

Hystrix manages all of that state internally. It won't interrupt or otherwise mess with commands that are already in flight at the time a circuit flips from CLOSED -> OPEN. At the point that happens, all commands get Short-Circuited, until the first command after the sleep duration. That single command executes (all others being short-circuited).

Does that answer your question?

[likebean]

for example，there are many requests (100) start execute in close status，and some requests (10) finish and cause status translate to open，and after delay time translate to half open，at this point only one request named A start execute，but before A finish execute，other slow executed request(90) start in init close status finish execute，and cause status changed，not request A.

[mattrjacobs]

Each command checks the circuit-breaker status once, and very early in its lifecycle. If the circuit-breaker is CLOSED, it proceeds, and if it is OPEN, it fails fast and goes to fallback.

I think that, rather than considering a batch of 100 requests, you consider a stream of requests happening at n reqs/sec. As that stream of requests executes, at some time t, the circuit-breaker transitions from CLOSED->OPEN. At that point, any command that checks the circuit-breaker status will see it OPEN and fail fast. Once the command has checked the circuit-breaker, it does not matter is the circuit-breaker flips, because it does not get checked again for that command instance.

[likebean]

my question is not about command check.my question is circuit breaker status change may caused by pre slow executed commands.

[mattrjacobs]

I'm still not quite clear on your question here. I think that your question is around some warm-up requests taking longer, and possibly encountering more errors/latency than steady-state requests.

If that's the case, then Hystrix will be more likely to open circuits during warmup.

[wangchangbing]

can Hystrix support the last 3 out of 5 executions succeed to change closed?

[mattrjacobs]

@wangchangbing Not at the moment. This could be done with #9, but that work has not been done yet

[mattrjacobs]

Closing due to inactivity. Please re-open if there's more to discuss