Open wavesZh opened 4 years ago
Good suggestion. This could be helpful for sparse slow requests. We could discuss the detail of the strategy here :)
Any thoughts? (maybe combine with concurrency control?)
Could you give me more informations about it? I am confused about sparse slow requests and concurrency control because I can not associate them with my issuse.
IMHO, the PR #1490 seems did not fix this issue.
The main point of problem is that Whether the Sentinel circuit breaker can cut off the traffic when it know inflight entries will trigger the breaker finally,instead of all unexpected slow entries exit
At some implementations such as hystrix , another thread will perform some fallback work when a actual working thread does not return after a timeout. With the current structure of Sentinel, it is not suitable to achieve a similar implementations, but some designs can be used to achieve the same effect:
SlowRequestLeapArray
should be calculated by maxAllowedRt/statIntervalMs
, and the window length should be setted as statIntervalMs
.SlowRequestCounter
should count inflight entries and track predecessor deprecated bucket after reset()
.tryPass()
should increment total, inflight, slow counter, and each new window should check prev inflight request once.onRequestComplete()
should decrement inflight and slow counter optionally, when that is slow entry, it also check current window.I will try to work on it, any other thoughts? ;-)
Issue Description
Type: feature request
Describe what happened (or what feature you want)
Now degrading by RT only consider finished requests because rt stat is collected when exit, but it ingores inflight requests. I thinks it is not accurate: When the count of inflight and overtime requests has exceeds threshold, but Sentinel will allow the below requests.
Describe what you expected to happen
Tell us your environment
Anything else we need to know?