Remote: Don't blocking-get when acquiring gRPC connections.
With recent change to limit the max number of gRPC connections by default, acquiring a connection could suspend a thread if there is no available connection.
gRPC calls are scheduled to a dedicated background thread pool. Workers in the thread pool are responsible to acquire the connection before starting the RPC call.
There could be a race condition that a worker thread handles some gRPC calls and then switches to a new call which will acquire new connections. If the number of connections reaches the max, the worker thread is suspended and doesn't have a chance to switch to previous calls. The connections held by previous calls are, hence, never released.
This PR changes to not use blocking get when acquiring gRPC connections.
Fixes #14363.
Closes #14416.
PiperOrigin-RevId: 416282883
diff --git a/src/main/java/com/google/devtools/build/lib/remote/UploadManifest.java b/src/main/java/com/google/devtools/build/lib/remote/UploadManifest.java
index 5dbbb07..b9b3912 100644
--- a/src/main/java/com/google/devtools/build/lib/remote/UploadManifest.java
+++ b/src/main/java/com/google/devtools/build/lib/remote/UploadManifest.java
@@ -354,8 +354,11 @@
try {
return uploadAsync(context, remoteCache, reporter).blockingGet();
} catch (RuntimeException e) {
- throwIfInstanceOf(e.getCause(), InterruptedException.class);
- throwIfInstanceOf(e.getCause(), IOException.class);
+ Throwable cause = e.getCause();
+ if (cause != null) {
+ throwIfInstanceOf(cause, InterruptedException.class);
+ throwIfInstanceOf(cause, IOException.class);
+ }
throw e;
}
}