If the server sends all response message but does not send the trailers, client throws
StatusRuntimeException: INTERNAL: Received unexpected EOS on DATA frame from server
DoNotMock was removed from error_prone_annotations in 2.1.3, because
there was no enforcement mechanism (which is in google/error-prone#572).
Guava and Trust also depend on error_prone_annotations and are beginning
to use newer versions, so our usage of DoNotMock is causing diamond
dependency problems. This allows us to update to 2.2.0.
The annotations were useful internally; we're solving that in cl/205294089.
This greatly reduces the amount of content. The removed content was
already deteriorating. For example, it references grpc-java-deploy which
is no longer present nor necessary. It also didn't suggest using
build_docker.sh for building protoc-artifacts.
While the docs could have been updated, without actually running them
they are unlikely to be functional. Removing the docs seems better than
spending effort of maintaining them, especially since they add confusion
to the process and are a scary amount of content for new devs.
The buildscript was updated to pull in a fix to protoc-artifacts to
support TLS 1.2 (google/protobuf#4879), which was the only remaining
reason to have our own container.
Docker container building was split out into a separate build_docker.sh
so that people can call it blindly and get the container necessary for
run_in_docker.sh.
We always want to use a consistent version of protobuf; avoid the need
for the caller (which may be a person running the script) to specify the
version.
Most of the changes are changing the signature of newClientTransport.
Since this is annoying, I choose to introduce a ClientTransportOptions
object to avoid the churn in the future.
With ClientTransportOptions in place, there's only a few lines necessary
of plumbing for the Attributes: add the field to ClientTransportOptions
and populate it in InternalSubchannel. There are no consumers of the
field in this commit.
This avoids the needs to flatten to EAGs for cases like PickFirst,
making the Attributes in EAGs able to be used in communication with
core. See #4302 for some discussion on the topic.
A new RPC starts with the following steps:
1. Pick a READY transport
2. the READY transport calls `transport.newStream()`
3. the new stream calls `stream.start()`
4. `stream.start()` invokes or enqueus `writeHeaders()` (or for GET request, noop)
A racy GOAWAY could happen between 3 and 4, and by the retry spec, the RPC should be transparent-retry-able in this case. For Netty and OkHttp transport implementation, before step 4, (even if step 1, 2, and 3 excluding 4 are made atomic,) the http2-stream for the RPC is not created, so the current transparent retry logic does not apply and need fix.
Of course, if step 1, 2, and 3 including 4 are made atomic, and not with GET, there will be no such problem.
Instead of failing after a a missing A/AAAA record, this change
makes the resolver keep going and try out SRV records too. This
is needed for use with ALTS, and is part of the gRPCLB spec.
This change also moved the JNDI code to a separate, reflectively
loaded file. This makes it easy to exclude the file and not worry
about the missing class references on Android. Additionally, if
javax.naming might be available on Android, this allows it to be
loaded. A key side effect of this is that DnsNameResolver is
smaller, and more cleanly tested.
The motivation here is in some cases we log the remote-addr that is set in the gRPC call attributes, and have to special case this type to support inprocess servers.
ZHANG Dapeng
Eric Gribkoff
Eric Anderson
Carl Mastrangelo
zpencer
Jiangtao Li
jbingham-google
Yang Song
Nick Hill
Marco Ferrer
sullis
Juanli Shen
Doug Lawrie
Shohei Kamimori