[L] Change in bazel/bazel[master]: Fix grpc connection pool race condition (https://github.com/bazelbuil...

0 views

Skip to first unread message

Copybara Service (Gerrit)

unread,

Jun 2, 2026, 5:27:02 AM (yesterday) Jun 2

to bazel-...@googlegroups.com

Copybara Service uploaded new patchset

Copybara Service uploaded patch set #4 to this change.

Open in Gerrit

Related details

Attention set is empty

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

open

diffy

Copybara Service (Gerrit)

unread,

Jun 2, 2026, 5:27:03 AM (yesterday) Jun 2

to bazel-...@googlegroups.com

Copybara Service submitted the change

Change information

Commit message:

Fix grpc connection pool race condition (https://github.com/bazelbuild/bazel/pull/29684)

Previously calling `withChannelConnection` claimed and closed a
connection from the `dynamicConnectionPool` instantly, even if there
were still remote exec requests in flight. This mean the connection went
back into the pool and would be reused by bazel even if it already had
the maximum number of MAX_CONCURRENT_STREAMS in flight. The end result
is that when you set `--jobs=500` your number of concurrent remote exec
actions could still be gated by `MAX_CONCURRENT_STREAMS` over a single
connection.

This seems to race based on how quickly bazel ends up creating another
connection before it closes the first one.

Related: https://github.com/bazelbuild/bazel/issues/11801

Closes #29684.

PiperOrigin-RevId: 925216366

Change-Id: Ic7744c6a92bbeb1df2ea5faeb83869403ef5dd96

Files:

M src/main/java/com/google/devtools/build/lib/remote/GrpcRemoteExecutor.java
M src/test/java/com/google/devtools/build/lib/remote/GrpcRemoteExecutorTest.java

Change size: L

Delta: 2 files changed, 190 insertions(+), 84 deletions(-)

Branch: refs/heads/master

Open in Gerrit

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

open

diffy

Reply all

Reply to author

Forward

0 new messages