• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

grpc / grpc-java / #19141
89%

Build:
DEFAULT BRANCH: master
Ran 03 Apr 2024 07:30PM UTC
Jobs 1
Files 556
Run time 150min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

03 Apr 2024 07:22PM UTC coverage: 88.301% (+0.06%) from 88.246%
#19141

push

github

web-flow
rls: Synchronization fixes in CachingRlsLbClient

This started with combining handleNewRequest with asyncRlsCall, but that
emphasized pre-existing synchronization issues and trying to fix those
exposed others. It was hard to split this into smaller commits because
they were interconnected.

handleNewRequest was combined with asyncRlsCall to use a single code
flow for handling the completed future while also failing the pick
immediately for thottled requests. That flow was then reused for
refreshing after backoff and data stale. It no longer optimizes the RPC
completing immediately because that would not happen in real life; it
only happens in tests because of inprocess+directExecutor() and we don't
want to test a different code flow in tests. This did require updating
some of the tests.

One small behavior change to share the combined asyncRlsCall with
backoff is we now always invalidate an entry after the backoff.
Previously the code could replace the entry with its new value in one
operation if the asyncRlsCall future completed immediately. That only
mattered to a single test which now sees an EXPLICIT eviction.

SynchronizationContext used to provide atomic scheduling in
BackoffCacheEntry, but it was not guaranteeing the scheduledRunnable was
only accessed from the sync context. The same was true for calling up
the LB tree with `updateBalancingState()`. In particular, adding entries
to the cache during a pick could evict entries without running the
cleanup methods within the context, as well as the RLS channel
transitioning from TRANSIENT_FAILURE to READY. This was replaced with
using a bare Future with a lock to provide atomicity.

BackoffCacheEntry no longer uses the current time and instead waits for
the backoff timer to actually run before considering itself expired.
Previously, it could race with periodic cleanup and get evicted before
the timer ran, which would cancel the timer and forget the
backoffPolicy. Si... (continued)

31165 of 35294 relevant lines covered (88.3%)

0.88 hits per line

Uncovered Existing Lines

Lines Coverage ∆ File
1
91.85
-0.22% ../netty/src/main/java/io/grpc/netty/NettyServerHandler.java
3
90.53
1.23% ../core/src/main/java/io/grpc/internal/DelayedClientCall.java
3
93.26
-1.69% ../core/src/main/java/io/grpc/internal/AbstractClientStream.java
4
78.95
-4.21% ../okhttp/src/main/java/io/grpc/okhttp/ExceptionHandlingFrameWriter.java
52
84.69
2.95% ../rls/src/main/java/io/grpc/rls/CachingRlsLbClient.java
Jobs
ID Job ID Ran Files Coverage
1 #19141.1 03 Apr 2024 07:30PM UTC 556
88.3
Source Files on build #19141
  • Tree
  • List 556
  • Changed 9
  • Source Changed 0
  • Coverage Changed 9
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #19141
  • 6e97b180 on github
  • Prev Build on master
  • Next Build on master
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc