No idle slots in nailgun pool when using JVM memory controls
#15808
Comments
|
Mm, shoot. Sorry for the trouble here. This is because the nailgun pool assumes that it is being run under a concurrency limit that would mean that the pool is always larger than the number of concurrent requests. As a workaround, you can lower https://www.pantsbuild.org/docs/reference-global#section-process-execution-local-parallelism to less than the number of slots in the pool. But we should remove that assumption (either by adding a semaphore around the pool... easier, or by implementing waiting inside of the pool... harder) in order to fix this. |
This was referenced Jun 21, 2022
stuhood
added a commit
that referenced
this issue
Jun 23, 2022
… the process parallelism (#15903) As described in #15808, the assumption that the nailgun pool runs under an appropriately sized semaphore has not been true since #15224, and results in an error when memory controls cause the pool size to be smaller than the process parallelism. To resolve that, we add an additional semaphore (and blocked workunit) to pool acquisition. Fixes #15808. [ci skip-build-wheels]
stuhood
added a commit
to stuhood/pants
that referenced
this issue
Jun 23, 2022
… the process parallelism (pantsbuild#15903) As described in pantsbuild#15808, the assumption that the nailgun pool runs under an appropriately sized semaphore has not been true since pantsbuild#15224, and results in an error when memory controls cause the pool size to be smaller than the process parallelism. To resolve that, we add an additional semaphore (and blocked workunit) to pool acquisition. Fixes pantsbuild#15808. [ci skip-build-wheels]
stuhood
added a commit
that referenced
this issue
Jun 23, 2022
… the process parallelism (Cherry-pick of #15903) (#15905) As described in #15808, the assumption that the nailgun pool runs under an appropriately sized semaphore has not been true since #15224, and results in an error when memory controls cause the pool size to be smaller than the process parallelism. To resolve that, we add an additional semaphore (and blocked workunit) to pool acquisition. Fixes #15808. [ci skip-build-wheels]
stuhood
added a commit
to stuhood/pants
that referenced
this issue
Jun 24, 2022
… the process parallelism (pantsbuild#15903) As described in pantsbuild#15808, the assumption that the nailgun pool runs under an appropriately sized semaphore has not been true since pantsbuild#15224, and results in an error when memory controls cause the pool size to be smaller than the process parallelism. To resolve that, we add an additional semaphore (and blocked workunit) to pool acquisition. Fixes pantsbuild#15808. [ci skip-build-wheels]
stuhood
added a commit
that referenced
this issue
Jun 24, 2022
… the process parallelism (Cherry-pick of #15903) (#15917) As described in #15808, the assumption that the nailgun pool runs under an appropriately sized semaphore has not been true since #15224, and results in an error when memory controls cause the pool size to be smaller than the process parallelism. To resolve that, we add an additional semaphore (and blocked workunit) to pool acquisition. Fixes #15808. [ci skip-build-wheels]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
when trying to use the JVM memory controls in 2.12rc2 with following settings in
pants.toml:And the running any Pants goal on JVM targets, it can be seen how Pants launches some nailgun servers to do some work but to end up exiting with following error:
Pants version
2.12rc2
OS
MacOS
Additional info
The text was updated successfully, but these errors were encountered: