[
https://issues.apache.org/jira/browse/SCB-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haishi Yao resolved SCB-2077.
-----------------------------
Fix Version/s: java-chassis-2.1.2
java-chassis-1.3.1
Resolution: Fixed
> The state of ServiceCombServerStats may be broken and the isolated servers
> never be tried
> -----------------------------------------------------------------------------------------
>
> Key: SCB-2077
> URL: https://issues.apache.org/jira/browse/SCB-2077
> Project: Apache ServiceComb
> Issue Type: Bug
> Components: Java-Chassis
> Affects Versions: java-chassis-1.3.0, java-chassis-2.0.1,
> java-chassis-2.0.2, java-chassis-2.1.0, java-chassis-2.1.1
> Reporter: Haishi Yao
> Assignee: Haishi Yao
> Priority: Major
> Fix For: java-chassis-1.3.1, java-chassis-2.1.2
>
>
> In some cases the users may run the invocation procedure in the custom thread
> pool and terminate it when the business timeout. Such use cases may break the
> reset operation of
> org.apache.servicecomb.loadbalance.ServiceCombServerStats#globalAllowIsolatedServerTryingFlag
> and leave the flag always false, which causing that no isolated server can
> get the trying chance anymore and the isolated servers can never recover from
> the isolated state.
> The solution is to store the Invocation instance applying the trying chance
> and the timestamp of applying. When the invocation procedure is over, the
> flag will be released. Or if there is something wrong and the releasing
> operation is interrupted, the state can be recovered according to the result
> of Invocation#isFinished or whether the period of chance occupation is longer
> than the maxSingleTestWindow.
> New config item is added, in order to limit the max length of period of
> trying chance occupation(time unit is millisecond):
> {code:java}
> servicecomb.loadbalance.isolation.maxSingleTestWindow
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
