Use call executor and scheduled executor service to schedule and run `retry()`.
Backoff amount computation from retry policy and testcases during backoff will be added in future PRs.
It's more reasonable and convenient to return a `Runnable` for `commit()` method because we want to execute part of the commit under a lock and run part of it out of the lock.
I think the idle state transitions are correct. I have looked at them and tried tracing a few paths through. This doesn't go full idle because the name resolver doesn't need to be restarted. Also, the LB transition happens inside of a NR callback, so it would be odd to have the NR terminate itself upon successful resolution. (Might this cause recursion? I think it may).
Spies are really magical and easily produce unexpected results. Using them in
tests can easily yield tests that don't do what you think they do. Delegation
is much safer when possible.
Delegation doesn't work when methods `return true`, final methods, and with
restricted visibility, though. So CensusModulesTest and
MaxConnectionIdleManagerTest are left as-is.
As delayedTransport `shutdown` will make retry attempts that are in backoff unable to create new stream. So wrap delayedTransport with `retriableTransport`, which will keep uncommitted retriable streams alive when `shutdown`.
Using META-INF for loading the version is broken on Android and
frequently broken when gRPC is shaded. Having hard-coded strings be
replaced on version bumps has been working well.
Fixes#2098
`ManagedChannelImpl` and `OobChannelq now both have a package
private field `ChannelStats`. There will be an internal access
API coming in a follow up PR.
The channelz service must not live in io.grpc.internal, and channelz
needs to be able to get the identifier of the entities it
tracks. Since io.grpc can not refer to io.grpc.internal, the LogId
must be moved out of internal.
With an approach using a variant of `DelayedStream` - `RetriableStream`.
`RetriableStream` is a logical stream per call that can create a sequence of `substreams`, the physical streams for the retry attempts. It could also create a family of substreams in parallel in hedging case.
`RetriableStream` buffers, delays and executes stream operations before `passThrough`, where `passThrough` is meant by `commit` as well as the buffer `drained` by the winning substream.
This PR only implements buffering messages and replaying buffered messages when retry.
Retry policy, hedging, transparent retry, backoff, max buffer size and APIs that users can enable retry are not included in this PR.
Each MethodDescriptor will have a binary log, though the log may
be a noop log. The binary log class is a skeleton class at the
moment, but does contain the max header and message length
info. The limits are determined by parsing the shell variable
GRPC_BINARY_LOG_CONFIG.
Previously it was 20s. 20s isn't _bad_, but may be too aggressive.
Having it longer doesn't hurt us too much; we just need some bound.
Since the MAX_BACKOFF on client-side is 120s, this will have client and
server match, except for jitter. Although I will note that the
client-side value covers more work than the server-side, such as
attempting to connect to multiple hosts.
zpencer
ZHANG Dapeng
Carl Mastrangelo
Eric Anderson
Shohei Kamimori
Kun Zhang
Eric Gribkoff
kenji yoshida