Server side caching completely broken

SonarQube Server / Community Build
, , ,
1

Sonar’s server side caching is completely broken:

w2:~ jude$ cat log | grep "was able to leverage cached"
[INFO] Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 94 files. These files will not be parsed.
[INFO] Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 246 files. These files will not be parsed.
[INFO] Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 10 files. These files will not be parsed.
[INFO] Server-side caching is enabled. The Java analyzer was able to leverage cached data from previous analyses for 0 out of 209 files. These files will not be parsed.
...

This is probably why my PR analyses take 27 minutes to complete. The bigger question is, how does one debug this? What could be going wrong? We’re using sonar scanner 5.5.0.6356 (maven/java), and sonarqube version v2025.6 (117042).

I checked the docker container running, and it’s been up for 5 weeks, so container restarts can’t be the reason.

3

hey Tylor - the link you referred to is a “Best video editor for android“. Some AI glitch?

Anyway - how can I get the key that sonar uses to generate this? Our CI is pretty solid when it comes to repeatability - JVM version, maven version, etc is all pinned. Why would checkout dir affect this cache? It’s most likely a temp checkout dir, which is then made the current working directory, and then all commands are executed from there. projectKey, sources, etc are the same. I am talking about multiple builds within the same PR/branch, which can’t even reuse their own analysis cache. And of course, the JVM version running sonarqube server is different from that running in CI, but I fail to see why would this make a difference, since the scanner who scans and generates a cache payload is always run with the same Java version.

4

Hi,

The docs on the caching process may help. From that I want to call out a couple of points:

So it’s worth asking when was the underlying branch last analyzed.

And one more from the docs:

So small changes with sweeping impacts would necessarily mean the cache was unusable (although your cache hit miss results are suspicious even for that.)

 
Ann

5

Hey Ann,

Thanks for that - seeing as we’ve hit our max lines of code, it does make sense that no cache is being used.

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.