ProjectFileIndexer exceptions in SonarQube

author Richard Fennell calendar Oct 31, 2024 · 2 min read  ·
Share on: linkedin copy

The Issue

We are running our SonarQube instance as an Azure hosted Docker container.

Over the past few weeks we have been seeing intermittent occurrences of the ProjectFileIndexer exception during the SonarQube analysis step in our Azure DevOps pipelines.

##[error]java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.filesystem.ProjectFileIndexer

When I looked closer at the exception stack, I could see at the bottom there was always a timeout error when trying to access the project.protobuf file from SonarQube.

Caused by: java.lang.IllegalStateException: Fail to request url: https://sonarqube.mydomain.co.uk/batch/project.protobuf?key=mykey

If I tried to open the URL in a browser, authenticated with SonarQube, most of the time the expected project.protobuf file was returned, but sometimes it was not.

Also, at random times, the SonarQube UI would take many seconds to refresh when I selected a project.

The Solution

In the past I have usually found any issues with SonarQube are ElasticSearch related, but not so this time.

The issue turned out to be a lack of SQL resources.

Our SonarQube instance was running on

  • Azure Web App (Premium V3 P1V3 2vCPU & 8Gb)
  • Azure SQL DB (Standard S2 50 DTU)
  • Logs/Config/ES indexes etc/ on Azure Standard General Purpose V2) File storage

When I look at the Azure SQL Query Performance Insights, I could see that the SQL DTU resources were maxing out at 100% for long periods of time, this occurred especially when the SonarQube analysis was restarted.

I increased the SQL resource to a Standard S3 100 DTU, the scaling took 15 minutes or so. Once this was done, the issue seemed to be resolved, though it is always hard to be sure with intermittent issues.

My assumption is that there are some SQL queries that are slow to run and are potentially blocking to other queries. By increasing the SQL resources, the these queries could be processed more quickly, and the blocking reduced to a level where it was not an issue.

You can see the impact of the change in the SQL DTU usage graph below. After the increase in SQL resources, we are not maxing out the server DTUs, so the SonarQube analysis can running without issues.

SQL DTU usage graph

I think the key take away is to make sure you have enough SQL resources, don’t max out your assigned DTUs, as this will cause issues.

For the original version of this post see Richard Fennell's personal blog at ProjectFileIndexer exceptions in SonarQube