Bazel 4.2.1 doesn't respect --remote_max_connections #14178
Assignees
Labels
P1
I'll work on this now. (Assignee required)
team-Remote-Exec
Issues and PRs for the Execution (Remote) team
type: bug
Milestone
Comments
|
Is this present in Bazel at head? We've just cut the 5.0.0 release, and are preparing to test and verify it, so this could be addressed in that. |
|
Not sure why but The difference between That said, I do think we should provide a way to set the max connections for grpc remote cache/execution. Reusing |
coeuvre
added
team-Remote-Exec
Wyverald
pushed a commit
that referenced
this issue
Nov 16, 2021
…ons. `--remote_max_connections` is only applied to HTTP remote cache. This PR makes it apply to gRPC cache/executor as well. Note that `--remote_max_connections` limits the number of concurrent connections. For HTTP remote cache, one connection could handle one request at one time. For gRPC remote cache/executor, one connection could handle 100+ concurrent requests. So the default value `100` means we could make up to `100` concurrent requests for HTTP remote cache or `10000+` concurrent requests for gRPC remote cache/executor. Fixes: #14178. Closes #14202. PiperOrigin-RevId: 410249542
|
Cherrypicked \o/ |
limdor
pushed a commit
to limdor/bazel
that referenced
this issue
Nov 24, 2021
…ons. `--remote_max_connections` is only applied to HTTP remote cache. This PR makes it apply to gRPC cache/executor as well. Note that `--remote_max_connections` limits the number of concurrent connections. For HTTP remote cache, one connection could handle one request at one time. For gRPC remote cache/executor, one connection could handle 100+ concurrent requests. So the default value `100` means we could make up to `100` concurrent requests for HTTP remote cache or `10000+` concurrent requests for gRPC remote cache/executor. Fixes: bazelbuild#14178. Closes bazelbuild#14202. PiperOrigin-RevId: 410249542 (cherry picked from commit 8d5973d)
meteorcloudy
pushed a commit
that referenced
this issue
Nov 24, 2021
…ons. (#14318) `--remote_max_connections` is only applied to HTTP remote cache. This PR makes it apply to gRPC cache/executor as well. Note that `--remote_max_connections` limits the number of concurrent connections. For HTTP remote cache, one connection could handle one request at one time. For gRPC remote cache/executor, one connection could handle 100+ concurrent requests. So the default value `100` means we could make up to `100` concurrent requests for HTTP remote cache or `10000+` concurrent requests for gRPC remote cache/executor. Fixes: #14178. Closes #14202. PiperOrigin-RevId: 410249542 (cherry picked from commit 8d5973d) Co-authored-by: Chi Wang <chiwang@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem:
There is a problem with Bazel 4.2.1. For some reason, it does not respect the --remote_max_connections flag. Builds that run with this version of Bazel open up thousands of sockets when they should in fact be restricted to 100.
We do not see this behavior with Bazel 4.0.0.
When using socketstat (we do here always a build with a remote cache - the system has around 240 sockets open before Bazel starts) we see a large increase of max sockets:
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
TODO (we work on it)
What operating system are you running Bazel on?
Ubuntu 20.04 LTS
What's the output of
bazel info release?release 4.0.0orrelease 4.2.1Have you found anything relevant by searching the web?
Nope.
Further notes
We are using Buildbarn
The text was updated successfully, but these errors were encountered: