SonarQube background tasks failing with IllegalArg

Question

We updated Sonarqube to version 5.2. After it, some Java projects start failing with following exception:

    2015.12.22 02:42:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Execute component visitors | time=9942ms        
    2015.12.21 13:01:45 ERROR [o.s.s.c.t.CeWorkerRunnableImpl] Failed to execute task AVHFtA0KaMG72s7lWjEx
            java.lang.IllegalArgumentException: Multiple entries with same key: MeasureKey{metricKey='lines', ruleId=-6253, characteristicId=-6253}=org.sonar.db.measure.PastMeasureDto@7493f7f3 and MeasureKey{metricKey='lines', ruleId=-6253, characteristicId=-6253}=org.sonar.db.measure.PastMeasureDto@1e7bae50
                at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150) ~[guava-17.0.jar:na]
                at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104) ~[guava-17.0.jar:na]
                at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70) ~[guava-17.0.jar:na]
                at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254) ~[guava-17.0.jar:na]
                at com.google.common.collect.Maps.uniqueIndex(Maps.java:1166) ~[guava-17.0.jar:na]
                at com.google.common.collect.Maps.uniqueIndex(Maps.java:1140) ~[guava-17.0.jar:na]
                at com.google.common.collect.FluentIterable.uniqueIndex(FluentIterable.java:424) ~[guava-17.0.jar:na]
                at org.sonar.server.computation.step.ComputeMeasureVariationsStep$VariationMeasuresVisitor.setVariationMeasures(ComputeMeasureVariationsStep.java:145) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.step.ComputeMeasureVariationsStep$VariationMeasuresVisitor.computeMeasuresWithVariations(ComputeMeasureVariationsStep.java:124) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.step.ComputeMeasureVariationsStep$VariationMeasuresVisitor.visitAny(ComputeMeasureVariationsStep.java:115) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitNode(DepthTraversalTypeAwareCrawler.java:60) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:44) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visitChildren(DepthTraversalTypeAwareCrawler.java:91) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.component.DepthTraversalTypeAwareCrawler.visit(DepthTraversalTypeAwareCrawler.java:47) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.step.ComputeMeasureVariationsStep.execute(ComputeMeasureVariationsStep.java:92) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:39) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.taskprocessor.report.ReportTaskProcessor.process(ReportTaskProcessor.java:53) ~[sonar-server-5.2.jar:na]
                at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.executeTask(CeWorkerRunnableImpl.java:78) [sonar-server-5.2.jar:na]
                at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.run(CeWorkerRunnableImpl.java:55) [sonar-server-5.2.jar:na]
                at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [na:1.7.0_45]
                at java.util.concurrent.FutureTask.runAndReset(Unknown Source) [na:1.7.0_45]
                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) [na:1.7.0_45]
                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) [na:1.7.0_45]
                at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.7.0_45]
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.7.0_45]
                at java.lang.Thread.run(Unknown Source) [na:1.7.0_45]

I have following plugins installed in Sonar

• Findbugs 3.3 (findbugs)
• C# 4.3 (csharp)
• Groovy 1.2 (groovy)
• Java 3.8 (java)
• LDAP 1.4 (ldap)
• Flex 2.2 (flex)
• PHP 2.4.1 (php)
• Build Breaker 1.1 (buildbreaker)
• JavaScript 2.8 (javascript)
• JIRA 1.2 (jira)

Answer 1

It seems that you have some corrupted past measures, probably due to missing analysis during migration or to other unexpected issues.

You'll have to clean up your database in order to continue the analysis. With SonarQube 5.3, you'll be able to know which component has corrupted past measures.

To find the duplicated measures to delete for a given component, you'll have to execute the following SQL query (replace by the key of the component) :

SELECT s.id, pm.metric_id, pm.rule_id, pm.characteristic_id FROM project_measures pm
INNER JOIN snapshots s ON s.id=pm.snapshot_id
INNER JOIN projects p ON p.id=s.project_id AND p.kee='<COMPONENT_KEY>'
INNER JOIN metrics m ON m.id=pm.metric_id
WHERE m.name='lines' 
AND pm.person_id IS NULL
GROUP BY s.id, pm.metric_id, pm.rule_id, pm.characteristic_id
HAVING count(*) > 1

Then, for each row returned, execute the following query (replace by the value of the s.id column, etc.) :

SELECT pm.* FROM project_measures pm 
INNER JOIN snapshots s ON s.id=pm.snapshot_id
WHERE s.id=<S_ID> AND pm.metric_id=<PM_METRIC_ID> AND pm.rule_id=<PM_RULE_ID> AND pm.characteristic_id=<PM_CHARCTERISTIC_ID>

You should have at least 2 rows returned by this query : it's the duplicated data that makes the computation of the project failing. You need to keep only one row by removing the other ones with :

DELETE FROM project_measures WHERE id=<PM_ID>

Please be careful to backup you database before deleting some data !

Answer 2

We also had this problem for type=DIRECTORY but there were no duplicated measures found using Julien's SQL query. The solution was to exclude each directory indicated in the thrown exception. This was done by adding patterns like the following to the exclusions list.

**/Implementations/Sales/**

Once analysis has completed successfully (can take multiple runs), you can then remove the exclusion(s) from the list and run again. Analysis will complete successfully and whatever content caused the problem will have been flushed out.