Sonarqube scanner is failing with JOURNAL_FLUSHER warning for a relatively small java project

SonarQube
,
1

Hello,

I have a Gradle project where I’m using Sonarqube scanner for Gradle (version 2.6.2). My SonarQube server is version 7.0. But, I have had this issue with Sonarqube server 6.5 and lower version of Gradle Scanner also.

The problem is isolated to a single project. This project is relatively small. It takes less than 5 minutes to compile and build the project. Sonarqube scan also takes about 5 minutes to finish, when it works.

Occasionally (seems often lately), the sonarqube task is failing after running for about 20 - 25 minutes. When it fails, it has following JOURNAL_FLUSHER warnings at the end:

[JOURNAL_FLUSHER] WARNING Journal flush operation took 4,411ms last 8 cycles average is 551ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 43,547ms last 8 cycles average is 5,994ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 35,993ms last 8 cycles average is 9,942ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 8,565ms last 8 cycles average is 1,070ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 51,592ms last 8 cycles average is 6,449ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 13,225ms last 8 cycles average is 8,102ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 15,825ms last 8 cycles average is 1,978ms
[JOURNAL_FLUSHER] WARNING Journal flush operation took 21,959ms last 8 cycles average is 4,723ms
:sonarqube FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonarqube'.
> Can not execute Findbugs with a timeout threshold value of 600000 milliseconds

I tried increasing the timeout value for this project in Sonarqube server, but that doesn’t seem to help. As I mentioned, sometimes it works just fine and finishes within 5 minutes. Also, the issue is not isolated to a single machine. This failure happens randomly when sonarqube task is run by the CI process, which uses one of several build servers.

I have this same process (Gradle based build) for several other java projects and they never have this issue. This is the only project that is causing issue.

Has anyone ran into this before? I have been googling about this but didn’t find something that I could follow along. If you have experience dealing with this issue, would you be able to shed some light on how to debug the issue and find the root cause?

2

Hi,

The error cites FindBugs. Have you tried uninstalling that plugin? BTW, simply removing its rules from your profile won’t prevent the plugin from running, which is a problem in that plugin.

Ann

3

Hi Ann,

Thank you for your reply and the suggestion. I haven’t tried uninstalling FindBug plugin. My main problem is that I can’t consistently recreate the problem. So, it’s not like if I don’t have FindBugs plugin, everything is okay. Even with that plugin installed, sometimes everything works just fine. And this inconsistent issue is only isolated to one particular project. As I mentioned, the project itself is very small and when it works successfully, it’s done under 5 minutes or so.

4

@ganncamp - I had already tried setting up following environment variable before executing Gradle’s sonarqube task.

export GRADLE_OPTS="-Xmx1536m -XX:MaxPermSize=384m -XX:ReservedCodeCacheSize=128m"

It doesn’t seem to help. I noticed in the doc, that there’s a different environment variable for installable sonarqube scanner:

export SONAR_SCANNER_OPTS="-Xmx512m"

Does that apply even when I’m using Sonarqube scanner for Gradle?

5

Hi,

I think it probably does. My understanding is that the SonarQube Scanner for Gradle invokes the vanilla scanner under the covers.

Ann

6

I just tried it but that didn’t seem to help fix the issue in my case. This is how I’m running sonarqube scan:

export SONAR_SCANNER_OPTS="-Xmx1536m"
gradlew sonarqube

I still seem to be getting the errors originally reported. So, I don’t think the Gradle based scanner used that environment variable unless I needed to set it in a different way since Gradle runs under a JVM.

7

Hello Ann,

I got this error on some gradle builds of us, too, after updating from sonar 5.5 to sonar 6.7.3. We have findbugs configured, but I think we need some of its checks. The question for me are

a) is there an alternative for findbugs getting the samechecks (if not disabling findbugs is no solution but only a temporar workaround)
b) can you tell which checks are responsible for this problem so we could disable them?

Best regards
Markus

8

Hi,

Unfortunately, FindBugs fires whether or not you’re actually using its rules, and no I don’t know which rules cause this.

Sorry I can’t be more help.

Ann

9

Hi Markus,

At SonarSource we maintain and continuously improve the SonarJava analyzer , which we believe covers pretty well Findbugs checks, and actually goes much further in terms of bug and vulnerability detection (with techniques like symbolic execution, taint analysis etc.). I don’t think this is a good place to go into details about SonarJava, but answering your question here: certainly you should check-out latest versions of SonarJava, review rules and even give it a spin on some projects of yours. It’ll give you a quick overview of the breadth of bugs/vulnerabilities/code_smells you can catch.

(and to be fully transparent: yes I’m part of SonarSource myself, and a good thing with SonarJava is that we’re able to fully follow-up and act on user feedback in this community, contrary to 3rd-party tools like FindBugs which are maintained by other parties)

Last but not least, and in the broader context of this thread: note that latest versions of SonarQube can import SpotBugs issues (FindBugs successor), letting you draw a clear line between FindBugs execution, and SonarQube analysis. See documentation here.

10

Hi Nicolas,
thanks for your answer, I think I will give sonarjava analyzer a try