-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bazel 4.2.1 doesn't respect --remote_max_connections #14178
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 |
…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/ |
…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)
…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 <[email protected]>
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.0
orrelease 4.2.1
Have 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: