-
-
Notifications
You must be signed in to change notification settings - Fork 759
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
GlobalClassLoaderCache: move call to getFiles out of synchronized block #3370
Conversation
…ynchronized block
Codecov Report
@@ Coverage Diff @@
## master #3370 +/- ##
============================================
+ Coverage 80.31% 80.44% +0.13%
Complexity 2721 2721
============================================
Files 445 445
Lines 8248 8250 +2
Branches 1566 1566
============================================
+ Hits 6624 6637 +13
+ Misses 785 772 -13
- Partials 839 841 +2
Continue to review full report at Codecov.
|
I guess @arturbosch is the best candidate to review this. I just have one question:
What makes you think that |
Thanks for the quick reply!
This is based on the thread dump that I provided in #3047:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks for investigating this hard issue.
Code looks good to me.
Yes, the other detekt invocations wait for the first one, but I still don't understand why getFiles
blocks/waits and who blocked it?
DefaultResourceLockCoordinationService.withStateLock
and DefaultWorkerLeaseService.acquireLocks
really look suspicious.
I'm okay with merging this and see in a RC release if this helps and/or does not introduce other issues.
Actually, I don't think #3799 has an impact on this PR, as IIUC the main point of this PR was to not do |
I haven't seen this issue recently so as far as I am aware it seems to have been fixed (although the intermittent nature doesn't rule out other confounding variables). 😅 And yes, that's my conclusion as well @sschuberth. |
Fixes #3047
This should fix the deadlock issue from #3047 by moving the call to
FileCollection.getFiles
out of thesynchronized
block inGlobalClassLoaderCache
. I am having a harder time reproducing the issue these days, but we are seeingDetekt
tasks hanging in our CI jobs ~1% of the time, which I suspect is caused by #3047. Hopefully we see those disappear after this change.I added an (admittedly contrived) test to verify that the cache doesn't call
FileCollection.getFiles
while synchronized on itself, which failed prior to this change but now passes. I also verified that I was able to run Detekt without issue on my own project.