-
-
Notifications
You must be signed in to change notification settings - Fork 822
GlobalClassLoaderCache: move call to getFiles out of synchronized block #3370
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
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:
|
arturbosch
left a comment
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.getFilesout of thesynchronizedblock inGlobalClassLoaderCache. I am having a harder time reproducing the issue these days, but we are seeingDetekttasks 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.getFileswhile 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.