-
Notifications
You must be signed in to change notification settings - Fork 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
Threads leaking from ForkJoinPool.commonPool (randomization in RandomCodec) #14066
Comments
Hmm... Interesting that I can't reproduce this locally. Also, ForkJoinWorkerThread should be demon threads, which are ignored by the default set of filters... Headscratch. |
This only happens with coverage tests. There is a difference in how these are started - they run without the security manager. Turns out ForkJoinPool's default factory has different settings for running with and without the security manager, resulting in system threads being either part of the test group or not. This is the direct reason why these tests pass in normal runs (most of those use the security manager) and fail with coverage runs (no security manager). |
thanks for debugging this: good find, since security manager won't be around forever... |
Thanks. If I read David Delabassee's e-mail correctly, JDK 24 effectively removes it internally. I've committed a quick patch to QuickPatchThreadsFilter to ignore those daemon threads. Sorry I didn't push it as a PR for review - seemed like a trivial change with no clear alternatives. If you'd like to run through the full cycle, I can revert and push a PR. |
no need for a hassle, thanks for fixing it. I will take care of the tidy. |
Damn. I'll do it, no problem. Sorry for the noise. |
Oh, you're fast. Thank you. |
Description
#14049 added randomization of codec params but as part of that it may spin up new threads when ForkJoinPool.commonPool is started. We have no control over these threads but they do cause test failures as in here:
I think we can safely assume common pool's threads surviving the test's scope are not interesting for us to detect and any leftover threads/ runnables will just eventually complete and die (?). I feel tempted to ignore those threads by adding them to QuickPatchThreadsFilter. If we want to ensure nothing survives the test's scope, we could add a rule to LuceneTestCase that would wait (after the suite completes) until the active count of workers in the common pool is zero.
Version and environment details
No response
The text was updated successfully, but these errors were encountered: