Previously, if the remote balancer doesn't close the stream after receiving the half-close, the OOB channel will hang there forever. It's safer to always cancel on the client-side so that the OOB channel can be cleaned up timely, regardless of what the remote balancer does.
* stub: ignore unary response msg if status is not OK
* stub: throw if no msg with OK status
* address the comment, improve tests.
* fix error message
* fix error message
* improve naming of the tests
* call onCompleted on success unary flow
* fix test
* handle errors for delayed unary message sending
* clean up the onCompleted/onError logic
* use hasMessageThat to produce better error message when fail
In 97cb0554 we pinned ourselves to trusty to workaround temporary Java 8
issues. Oracle JDK 8 is "dead" across the ecosystem because Oracle
removed download links to it, so we swap to openjdk 8 as we have done
elsewhere. OpenJDK 8 is supported with xenial, so we can upgrade.
Unfortunately bionic on Travis does not include openjdk8, so we will be
unable to easily upgrade to newer versions of the distro unless we drop
JDK 8 compilation or we figure out a way to get it working. For example,
in may be possible to install the openjdk-8-jdk package.
Adds an Executor to NameResolver.Args, which is optionally set on ManagedChannelBuilder. This allows NameResolver implementations to avoid creating their own thread pools if the application already manages its own pools.
Addresses #3703.
net_zlib is no longer used ("zlib" is used instead). Zlib and skylib are
both included via protobuf_deps(). With the language-specific rules
needing to be imported (e.g., rules_proto, rules_java) we are relying on
protobuf_deps() pretty heavily starting in Protobuf 3.10, so we aren't
losing much to remove these two deps.
This change added the missing implementation of HTTP/2 HPACK for writer. The implementation is copied (and modified) from upstream OkHttp (OkHttp3).
- Huffman encoding of writer is disabled by default.
This implicit loading is more conservative than the loading for
tcnative, as Conscrypt will only be implicitly loaded if there are no
other options. This means the Java 9+ JSSE is preferred over Conscrypt
without explicit user configuration.
While we would generally prefer Conscrypt over JSSE, we want to allow
the user to configure their security providers. There wasn't a good way
to do that with netty-tcnative and the performance of JSSE at the time
was abysmal.
While generally being a good way to allow adopting Conscrypt, this also
allows easily using App Engine Java 8's provided Conscrypt which can
substantially reduce binary size.
See googleapis/google-cloud-java#6425