API Changes
   
   - Static methods in Builders that always throw are now annotated 
   @DoNotCall. This annotation can be noticed by ErrorProne and inform you of 
   a mistake at compile time instead of runtime. This applies to static 
   methods like InProcessServerBuilder.forPort(int) which are inherited from 
   base classes like ServerBuilder/ManagedChannelBuilder yet are a bug if used.
   - api, core: Support zero copy into protobuf. New APIs have been added 
   to support the custom implementation of a zero-copy Protobuf 
   deserialization marshaller. The HasByteBuffer API exposes ByteBuffers 
   underlying the InputStream being passed to the Marshaller and 
   the Detachable API allows custom Marshaller to take over the ownership of 
   buffers for performing delayed deserialization.
   - NettyChannelBuilder supports SocketAddress with ChannelCredentials.

Bug Fixes
   
   - netty: Remove Maven pom.properties from netty-shaded jar. The 
   properties don’t add much value and mainly confuse tools in a shaded jar.
   - netty-shaded: Modify the shading operation to transform native-image 
   resources so they correctly reference shaded class names (#7540 
   <https://github.com/grpc/grpc-java/issues/7540>)
   - xds: Shut down the scheduledExecutorService in the CertificateProvider 
   when it is shutdown.
   - xds: Close the SslContexrProviderSupplier when a CDS LoadBalancer is 
   shut down to prevent leakage.
   - xds, grpclb: Use a standalone Context for control plane RPCs. The 
   existing behavior of implicitly using the Context in ThreadLocal can cause 
   control plane RPCs to be cancelled prematurely, in cases the data plane RPC 
   is made within a gRPC service to another service. To avoid being impacted 
   by data plane RPC lifecycle, the fix creates standalone Context for control 
   plane RPCs.
   - xds: cluster_resolver LB policy should wait until all clusters are 
   resolved before propagating endpoints to child LB policy. Previously, the 
   cluster_resolver LB policy propagated partially resolved results (endpoints 
   for a subset of clusters) to its child LB policy, which can cause RPCs to 
   be sent to less favored clusters before endpoints of more favored clusters 
   are discovered.
   - xds: use load assignment endpoint address in Cluster as the DNS 
   hostname for LOGICAL_DNS. The LOGICAL_DNS concept was misunderstood 
   previously. Instead of using the channel authority, the hostname should be 
   given by Cluster resource in CDS responses.
   - grpclb: skip fallback if the LB is already in fallback mode. An 
   invariant check for gRPCLB LB policy’s internal state introduced by #8035 
   <https://github.com/grpc/grpc-java/pull/8035> is broken in case the LB 
   policy is in fallback mode while receiving an address update without remote 
   balancer addresses. The fix mitigated the temporal invariant violation.

New Features
   
   - compiler: Add support for ppc64le on RHEL8.

Dependencies
   
   - Protobuf upgraded to 3.17.2
   - We now use custom Gradle logic to determine if Maven’s 
   requireUpperBoundDeps would fail for our published artifacts instead of 
   Gradle’s failOnVersionConflict. This means we now make use of fewer 
   dependency exclusions (#8238 
   <https://github.com/grpc/grpc-java/pull/8238>). failOnVersionConflict 
   has similar behavior to dependencyConvergence but we previously lacked a 
   more precise tool to detect cases where Maven would downgrade dependencies. 
   We strongly encourage all Maven users to use Maven Enforcer’s 
   requireUpperBoundDeps and continue to discourage using dependencyConvergence

Acknowledgements

@lepistone <https://github.com/lepistone> Leonardo Pistone
@shirodkara <https://github.com/shirodkara> Amit Shirodkar
@cfredri4 <https://github.com/cfredri4>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6cbbddb3-4951-4c84-b73e-be194f76aec6n%40googlegroups.com.

Reply via email to