Analysis cache detail usage

I would like to understand how to use this analysis cache feature correctly. I can’t find any document on this aside from how to enable it. Yes I have enabled it and it works from one workspace perfectly everything with 100% hit rate.

Question 1:
Is analysis cache per workspace? That is does it rely on path where the workspace is checked out?
It seems like the case for me. So locally I have master checked out in 2 locations and I am using the same cache path for both analysis. There are no hits between them when switching from one to another. Note: It is exact same source code. And if I work on one workspace I get 100% hit.

Question 2:
The above issue will cause problems with PR on Jenkins and branch builds as they are checked out at different locations. What is the best approach to handle cache and reuse between different locations of source tree?

Question 3:
I use for all my build types and use the same cache for all build type on Jenkins. When I say build type I mean master, branch build and pull requests. ie. on Jenkins master build and for PR and branch build Is this the way to do it to share the cache across from master to PR to branch builds?

I seriously need an urgent answer otherwise this tool is not useful with out cache speed up in PR.


Hello @Kamal_Chandra,

what cache feature? Could you please be more specific please?

This forum is not for urgent question, this is a polite place.

I am talking about analysis cache as detailed in the title and also the question. This is the caching if analysis so it does not analyse the unchanged files again.

Hi @Kamal_Chandra,

I am sorry but you are still not giving any context about your analysis and the languages you are trying to analyze. I could only guess and that is not the way to proceed.

Hi Massimo,

I am not sure how many types of sonarqube analysis there are. I am talking about C/C++ sonarqube analysis cache here.

Hi @Kamal_Chandra,

never give anything as implicit, SonarSource supports > 20 languages and there are tens of plugins available in the marketplace.

The cache depends on the absolute path too, checkouts at different paths are not supposed to use the same cache. Even more, cache should not be uses for parallel analysis.

You should look at having a stable checkout path, i.e. on /tmp.

Having only master build updating cache and PRs copying it from master without using it is a good solution. (You may be interested by this topic SonarCFamily Cache Question)

Thank you Massimo. I did look through other topics to come to this conclusion as well.

1 Like

Hi @mpaladin,

When you say cache should not be used for parallel analysis, what do you actually mean?

  • multiple builds using the same cache?
  • or one build running sonar analysis using -Dsonar.cfamily.threads=32?

If we do run in parallel what issues are we expecting here?
Why I ask this is we still see random exceptions that was already fixed in your new releases. java.lang.IllegalArgumentException: 174 is not a valid line for pointer.

at org.sonar.api.utils.Preconditions.checkArgument(
at org.sonar.api.batch.fs.internal.DefaultInputFile.checkValid(
at org.sonar.api.batch.fs.internal.DefaultInputFile.newPointer(
at org.sonar.api.batch.fs.internal.DefaultInputFile.selectLine(
at com.sonar.cpp.plugin.CFamilySensor.rangeOrLine(
at com.sonar.cpp.plugin.CFamilySensor.reportIt(
at com.sonar.cpp.plugin.CFamilySensor.process(
at com.sonar.cpp.plugin.CFamilySensor.process(
at com.sonar.cpp.plugin.CFamilySensor.execute(
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(
at org.sonar.core.platform.ComponentContainer.startComponents(
at org.sonar.core.platform.ComponentContainer.execute(
at org.sonar.scanner.scan.ProjectScanContainer.scan(
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(
at org.sonar.core.platform.ComponentContainer.startComponents(
at org.sonar.core.platform.ComponentContainer.execute(
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(
at org.sonar.core.platform.ComponentContainer.startComponents(
at org.sonar.core.platform.ComponentContainer.execute(
at org.sonar.batch.bootstrapper.Batch.doExecute(
at org.sonar.batch.bootstrapper.Batch.execute(
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(
at org.sonarsource.scanner.api.EmbeddedScanner.execute(
at org.sonarsource.scanner.cli.Main.execute(
at org.sonarsource.scanner.cli.Main.execute(
at org.sonarsource.scanner.cli.Main.main(

We are using SonarScanner and Analyzing on SonarQube server 8.3.1.

Thanks for your help.

Hi @Kamal_Chandra,

multiple parallel builds MUST not use the same cache instance in parallel.

one build running with multiple threads is perfectly ok, otherwise we would have disabled the feature.

Are you running multiple parallel analysis with the same cache?

Thanks @mpaladin. Always appreciate your quick responds. Yes I was tracking it down and our CI system (Jenkins) was running multiple builds on one machine and they both use the same sonar cache. We have stopped doing that and so far so good.

I think this was the issue that was causing the exception. I will let you know if it happens again.

1 Like

Hi @Kamal_Chandra,

great, thank you!

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