Release notes <https://github.com/grpc/grpc-java/releases/tag/v1.79.0>

API Changes

   - 
   
   core: Delete the never-used 
io.grpc.internal.ReadableBuffer.readBytes(ByteBuffer) 
   (#12580) (738782fb0). This is deeply internal and not accessible, so 
   shouldn’t impact anything. However, Apache Arrow Java uses reflection to 
   access private fields 
   
<https://github.com/apache/arrow-java/blob/96156ccc2bf933c75c852ca7c04418a61f87defd/flight/flight-core/src/main/java/org/apache/arrow/flight/grpc/GetReadableBuffer.java#L44-L45>;
 
   GH-939: Remove reflection for gRPC buffers 
   <https://github.com/apache/arrow-java/pull/954> is swapping to gRPC’s 
   public zero-copy APIs
   - 
   
   opentelemetry: Add target attribute filter for metrics (#12587). 
   Introduce an optional Predicate targetAttributeFilter to control how 
   grpc.target is recorded in OpenTelemetry client metrics. When a filter is 
   provided, targets rejected by the predicate are normalized to "other" to 
   reduce grpc.target metric cardinality, while accepted targets are recorded 
   as-is. If no filter is set, existing behavior is preserved. This change 
   adds a new Builder API on GrpcOpenTelemetry to allow applications to 
   configure the filter. 
   

Behavior Changes

   - 
   
   core: Convert AutoConfiguredLB to an actual LB (4bbf8eee5). This is an 
   internal refactoring, but it does improve how errors are handled for broken 
   binaries. Previously, not being able to load pick_first would result in a 
   channel panic. Now it is handled as a regular load balancing error
   - 
   
   okhttp: Assert no pending streams before transport READY (#12566) 
   (ed6d175fc). No pending streams should exist when the transport transitions 
   to READY. This PR adds an assertion to help verify this invariant.
   

Bug Fixes

   - 
   
   core: PickFirstLB should not return a subchannel during CONNECTING 
   (228fc8ecd). Pick-first in grpc-java has behaved this way since it was 
   created, and it was of no consequence. However, now there are some load 
   balancing policies (mainly RLS) that will do a pick() and hope the result 
   to be reasonably accurate for metrics.
   

Improvements

   - 
   
   core: Improve DEADLINE_EXCEEDED message for CallCreds delays 
   (ead532b39). Previously the error message contained “buffered_nanos” and 
   “waiting_for_connection” for connection delays. However, we discovered the 
   same strings were also used if waiting on CallCredentials. Now you’ll see 
   details like “connecting_and_lb_delay”, “call_credentials_delay”, and 
   “was_still_waiting”.
   - 
   
   opentelemetry: Add Android API checking (a9f73f4c0). Previously we 
   assumed OpenTelemetry support would not be used on Android. It did happen 
   to be compatible with Android, but since OpenTelemetry does have some 
   Android support, we now have a check that it remains compatible
   - 
   
   core: Catch Errors when calling complex config parsing code (a535ed799). 
   Error (and any other Throwable) is now caught and handled when parsing 
   configuration (e.g., service config, xds). This will cause such failures to 
   be handled gracefully instead of panicking the channel
   - 
   
   core: Implement LoadBalancer.Helper.createOobChannel() with the 
   internals of createResolvingOobChannel() (3915d029c). This API is only 
   expected to be relevant to the gRPC-LB lookaside load balancer, and is not 
   believed to have behavior changes. Out-of-band channel had been implemented 
   with its own stripped-down Channel without load balancing. Reimplementing 
   using the resolving oob channel makes it a full-fledged channel and reduces 
   the burden when integrating new features and allows us to have a 
   ManagedChannelBuilder to use with efforts like gRFC A110: Child Channel 
   Options <https://github.com/grpc/proposal/pull/529>.
   - 
   
   xds: Implement the proactive connection logic in RingHashLoadBalancer as 
   outlined in gRFC A61 (#12596). Previously, the Java implementation only 
   initialized child balancers when a ring-chosen endpoint was in 
   TRANSIENT_FAILURE during a picker's pickSubchannel call. This PR adds the 
   missing logic: when a child balancer reports TRANSIENT_FAILURE, the 
   LoadBalancer now proactively initializes the first available IDLE child if 
   no other children are currently connecting or ready.
   
This ensures a backup subchannel starts warming up immediately outside the 
RPC flow, reducing failover latency and improving overall resilience. This 
behavior was previously present but was inadvertently lost after #10610 
<https://github.com/grpc/grpc-java/pull/10610>.

   - 
   
   api: Add RFC 3986 support to DnsNameResolverProvider (#12602) 
   (f65127cf7) Experimental RFC 3986 target URI parsing mode (disabled by 
   default)
   

New Features

   - 
   
   opentelemetry: Actual reason for the disconnects in subchannel 
   metrics(6b2f7580c), completing the remaining work in gRFC A96: OTel 
   metrics for Subchannels <https://github.com/grpc/proposal/pull/485/files>
   

Dependencies 

   - 
   
   protobuf: Upgrade Bazel protobuf to 33.1 (#12553) (b61a8f49c) and load 
   java_proto_library from the protobuf repo (c7f3cdbc3)
   - 
   
   protobuf: Fix build with Bazel 9 by upgrading bazel_jar_jar and 
   grpc-proto versions (#12569)
   - 
   
   Upgrade dependencies (#12588) (6422092e3) Netty to 4.1.130, error-prone 
   annotations to 2.45.0, google-auth-library to 1.41.0, tomcat-embed-core9 to 
   9.0.113, tomcat-embed-core to 10.1.50, opentelemetry to 1.57.0, 
   jetty-ee10-servlet to 12.1.5, jetty-http2-server to 12.1.5, 
   google-cloud-logging to 3.23.9, google-auth to 1.41.0, 
   proto-google-common-protos to 2.63.2.
   

Thanks to

   - 
   
   @benjaminp
   - 
   
   @becomeStar
   - 
   
   @meteorcloudy
   

-- 
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 visit 
https://groups.google.com/d/msgid/grpc-io/31f4b202-b281-4296-8cc1-6ed113da344dn%40googlegroups.com.

Reply via email to