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
These changes avoid a dependency on automake, autoconf, and libtool. The
./configure script is only available via the release artifacts, not git.
For example, on Debian Buster only curl and build-essential need to be
installed.
`XdsNameResolver` will load bootstrap file and populate `Node` reference to the `XdsLoadBalancer` through attributes of `ResolvedAddresses`. This is only for demo purpose until `XdsClient` is available, whence `XdsNameResolver` will populate `XdsClient` reference to `XdsLoadBalancer` through attributes instead.
If a `LoadBalancer` implementation does not override `handleResolvedAddressGroups()`, or overrides `handleResolvedAddressGroups()` but calls `super.handleResolvedAddressGroups()` at the beginning or the end, it will be trapped in an infinite loop.
Moved `ManagedChannel initLbChannel(Helper helper, String balancerName)` out of `LookasideChannelLb` because `LoadReportClientImpl` need channel be initialized already.
Migration will be in an upcoming PR.
This change reimplements Bootstrapper with new design of bootstrap file format, with no longer using ApiConfigSource proto. The new JSON format of the bootstrap file contains a top level "node" and a "xds_server" object, which contains a "server_uri" string and a `channel_creds` list for channel credentials.
Unknown fields in the bootstrap file are allowed by ignored so that the implementation does not break when new fields are added in the future. Therefore, we cannot simply create a custom proto file and use proto util to parse it.
We depend on Conscrypt to help ensure Conscrypt 2.1.0 or newer is used.
It's not 100% clear this is the best approach, but it is the simplest at
present. If Conscrypt is not available then we will just use the JDK's
slower implementation of AES-GCM.
Fixes#6213
This change adds two booleans to the ChannelBuilders to
allow transports to use get and put. These are currently defaulted to
on, but unset on the method descriptors. This change is 1/2 that will
allow the safe / idempotent bits to be set on generated proto code.
Part 2/2 will actually enable it.
The use case for this is for interceptors that implement caching logic.
They need to be able to access the safe/idempotent bits on the MD in
order to decide to how to handle the request, even if gRPC doesn't use
GET / PUT HTTP methods.
* cronet: update README for using published grpc-cronet with play service Cronet implementation.
* doc: Added cronet/README.md version update to RELEASING.md.
- Implementing priority failover
- Removed `localityWeight` field from `LocalityLbInfo` because this is always available and up to date in `edsResponsLocalityInfo`, otherwise need to create a new instance of `LocalityLbInfo` each time weight is updated.
- Introduced `PriorityManager` that manages all the priority failover logic.
Eric Anderson
cmagnuso244
sanjaypujare
dapengzhang0
Jihun Cho
Chengyuan Zhang
Przemek Piotrowski
Carl Mastrangelo