SonarQube Community Edition background task queue limits
0 reputation · 07 Feb 2023, 03:11 UTC
0 reputation · 07 Feb 2023, 03:11 UTC
In SonarQube Community Edition, the server processes analysis reports asynchronously via a background task queue. For environments with low-traffic workloads, reducing hardware allocations to minimize costs is a common objective.
However, the Community Edition utilizes a specific processing model for these tasks. There is uncertainty regarding how the system handles concurrent submissions when CPU and RAM are constrained to minimum specifications, specifically concerning the impact on the task queue when multiple scanners submit reports simultaneously.
What are the specific concurrency limits for background task execution in the Community Edition? Does the system support configurable task parallelism, or is it restricted to a single-threaded processing model regardless of available hardware?
30275 reputation · 07 Feb 2023, 09:41 UTC
The Community Edition uses a bounded task queue to manage asynchronous analysis reports. The queue capacity is controlled by the sonar.taskQueueSize property, which defaults to 1,000 tasks. When the queue is full, new submissions are either rejected or deferred based on the sonar.backgroundTaskQueueRejectionPolicy setting.
Concurrency for actual task execution is not governed by a single parallelism knob in Community Edition. Instead, SonarQube runs worker threads from a JVM-managed pool that adapts to available CPU and heap. Reducing hardware allocations to minimize costs will therefore limit the number of tasks that can run simultaneously, even if the queue itself has remaining capacity.
$SONAR_HOME/conf/sonar.properties.sonar.taskQueueSize to your desired maximum (e.g., 2000).Task queue size set to X messages.If tasks are being dropped, also review sonar.backgroundTaskQueueRejectionPolicy (values include FAIL, DROP, etc.).
In SonarQube 9.x LTS the default sonar.taskQueueSize is 1,000. Later versions may increase the default or introduce dynamic sizing, but Community Edition typically retains stricter fixed limits compared to the Enterprise Edition. To tailor the recommendation to your exact setup, could you share the SonarQube version in use? This helps confirm whether default limits have changed or if dynamic queue sizing is available.
Use comments to ask for clarification. Post a solution as an answer.
3,360 reputation · 07 Feb 2023, 09:18 UTC
The existing answer describes queue capacity settings, but it's important to clarify that SonarQube Community Edition enforces a strictly single-threaded Compute Engine. The sonar.ce.workerCount property is ignored in CE — it only takes effect in Developer, Enterprise, and Data Center editions. All analysis reports are dequeued and processed sequentially by one worker thread, no matter how many CPU cores or how much RAM you allocate.
Concurrent scanner submissions simply accumulate in the database-backed queue (visible under Administration → Background Tasks or via /api/ce/task) and wait their turn. There is no built-in rejection or backpressure mechanism; the queue grows until tasks are processed. If you're seeing tasks stuck in PENDING, the bottleneck is the single worker, not the queue size setting.