* okhttp: forked required files to make okhttp dep compile only
* okhttp: forked missing file to make okhttp dep compile only
* okhttp: moved url and request files to proxy packge
* okhttp: removed unused methods from forked files; fixed build
This would limit ADS stream creation to one per second, even if the
old stream was considered good as it received a response. This shouldn't
really ever trigger, and if it does 1 QPS is probably still too high.
But 1 QPS is _substantially_ better than a closed loop and there's very
few additional signals we could use to avoid resetting the backoff.
b/224833499
protoc-gen-grpc-java isn't useful in a BOM because the Gradle plugin
doesn't support BOMs (google/protobuf-gradle-plugin#412) and it seems
unlikely the Maven plugin would as well.
Right now the type is pom, which is useless; nobody cares about the pom
itself. We'd need to use a type of exe and repeat it for each platform
(classifier). Given that it is a strange case and we can't actually test
the results and having it in the bom might lead a user to trying to make
it work, let's just remove it for now until it provides value.
Fixes#8936
Currently the credentials used for xDS communications is hardcoded in the BootstrapperImpl. The bootstrap config chooses one of the possible hardcoded credential.
This commit adds support for a credential plugin which allows users to register custom credentials through XdsCredentialProviders. gRPC will automatically discover the implementations via Java's SPI mechanism
Bootstrapper will use XdsCredentialRegistry to retrieve the list of supported credentials. The current hardcoded list of credentials(google_default, insecure and tls) are registered by default to keep the behavior as is.
Doing any reflection on OkHttpChannelBuilder requires that all methods
can have their arguments resolved. We'd like to make okhttp an optional
dependency (to support okhttp 2 and 3/4 simultaneously). But making
okhttp optional means we can no longer construct OkHttpChannelBuilder
reflectively. We swap to the Provider that doesn't have this problem.
See #8971.
Note that ManagedChannelProvider itself only exposes its methods as
protected, so they wouldn't be accessible. However OkHttpChannelProvider
has its methods public. It is an open question of whether
ManagedChannelProvider's methods should become public, but in any case
we can hide a public OkHttpChannelProvider inside a package-private
class so it is only accessable via reflection. So this code assuming
public methods doesn't prevent future implementation hiding.
We want to ignore the route in these situations, which is achieved by returning a null. The current behavior of returning an error triggers a NACK to the update.
We shouldn't require addresses to be non-empty for the child lb of rls_lb. That might be a right requirement when the child lb is grpclb, but in our new usecase, the child lb will be cds lb and will only work if empty address is allowed.
Fixing b/223866089#comment24
The previous code assumed that only gRPC would be using these methods.
But twice now Netty has made a change (generally relating to security)
that used a method for pseudo headers that previously wasn't supported.
Let's stop the whack-a-mole and just implement them all.
This restores compatibility with Netty 4.1.75.Final. Fixes#8981
* observability: integrate globalTags and configuration into rest of observability
wire observabilityConfig and globalTags into Observability and make
these available to the channel and server interceptors and specifically
to the LogHelper. Also separate globalTags into custom-tags and location-tags as required by the log-helper
This test suite is only fully enabled for C++ and Python at this
moment. This commit enables the rest of the test suite for grpc-java.
* change_backend_service_test
* failover_test
* remove_neg_test
* round_robin_test
* affinity_test
We are solving the issue of grpc/grpc delaying the release, causing GCE
tests to fail. Updating the master branch prevents similar cases from
happening.
Tested: [prod:grpc/java/master/branch/xds_v3](http://sponge/010f5353-e65e-4b1a-b6d3-f5a84e31546b)
If protoc is compiled with MinGW it will depend on libstdc++-6.dll which is found in C:\msys64\mingw64\bin and can only be found by inheriting PATH from the environment.
`setCall()` returns drainPendingCalls runnable only when there are calls to drain, otherwise return null. Preserved the behaviour of `start()` and `cancel()`, as they are protected by `delayOrExecute()`.
* stub: Have ClientCalls.ThreadlessExecutor reject Runnables after end of RPC
Changes originally proposed as part of #7106.
Fixes#3557
* add environment variable rejectExecutedException
Co-authored-by: Nick Hill <nickhill@us.ibm.com>
GoogleCloudToProdNameResolver has a hard dependency on alts whereas xds
only has a weak dependency on alts that can be solved by a
ChannelCredentialsRegistry. So split out the code to a separate
artifact.
Update javadoc to mention this previously-unwritten rule.
Update earlyServerClose_serverFailure_withClientCancelOnListenerClosed to obey it.
Update BinderTransport to fail sooner if this rule is broken.
2a45524 introduced '.' to the end of some status descriptions. We
typically don't end status descriptiosn in periods, but that's minor. In
this case though if the causal status ends in period then the new status
will end in two periods, which could easily be confusing to users.
added a java control plane for xds tests end-to-end.
The FakeControlPlaneService manages full sets of xds resources. Use `setXdsConfig()` method to update the latest xds configurations; the method can be called anytime and multiple times dynamically. The fake control plane allows multiple clients connecting, delivers xds responses(for the data resources, or ACK/NACK) for the xds client requests.
The `FakeControlPlaneXdsIntegrationTest` only has one pingPong test case now. Other test case can be added in a similar way.
Workaround for #8886, as we wait on a real fix. The regular load
balancing disconnections are confusing users and will train users to
start ignoring gRPC warnings. At present, it is better to have no log
than excessively log.