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.
The class is still used internally, so we move it to context's tests for
it to be reused. To avoid a circular dependency with context's tests
depending on core's tests, StaticTestingClassLoader was also moved to
context's tests.
This is driven by a need to modernize DeadlineSubject for newer versions
of Truth, but the newer versions of Truth update Guava. To avoid leaking
the Guava update to all users of grpc-testing, we're removing the
Subject. In our internal tests we can update the Truth dependency with
less issue.
handshakeTimeout is unnecessary for InProcess, and the scheduling is causing
Thread creation that is breaking restrictive test environments. Those
environments are mostly broken already because client-side will try to create
Threads as well, but they are currently lucking out that the exception on
client-side doesn't break much.
RPC upstarts are counted into metrics
RPC_{CLIENT,SERVER}_STARTED_COUNT. In addition, RPC completions are
counted into metrics RPC_{CLIENT,SERVER}_FINISHED_COUNT. From these
metrics, users will be able to derive count of RPCs that are currently
active.
This mainly copies documentation from other places, like StreamObserver
and ClientCall, but does fix some missing important threading notes.
Fixes#3413