diff options
author | Kun Zhang <zhangkun83@users.noreply.github.com> | 2018-02-22 09:27:08 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2018-02-22 09:27:08 -0800 |
commit | 46c1133a1ee49c14c7d0bc715cab9d1cf57db69c (patch) | |
tree | 5415e862505ab2643dcafc9dc51d15b9118b6828 /services | |
parent | 137c74d15f261efe9bab5242684afe9971c5965c (diff) | |
download | grpc-grpc-java-46c1133a1ee49c14c7d0bc715cab9d1cf57db69c.tar.gz |
core: add panic mode for ManagedChannelImpl (#4023)
Channel enters this mode whenever there is an uncaught throwable from
its ChannelExecutor, which is where most channel internal states are
mutated, such as load-balancing.
In panic mode, the channel will always report TRANSIENT_FAILURE as its
state, and will fail RPCs with an INTERNAL error code with the
uncaught throwable as the cause, which is helpful for investigating
bugs within gRPC and 3rd-party LoadBalancer implementations.
## Change to existing behavior
Previously if `LoadBalancer` throws in `handleResolvedAddressGroups()`, it would
be routed back to `LoadBalancer.handleNameResolutionError()`. Now it will make
the channel panic.
## Internal refactors
- Refactored out `shutdownNameResolverAndLoadBalancer()`, called from three code paths: `enterIdleMode()`, `delayedTransport.transportTerminated()`, and `panic()`.
- Refactored out `updateSubchannelPicker()`, called from both `updateBalancingState()` and `panic()`.
Diffstat (limited to 'services')
0 files changed, 0 insertions, 0 deletions