Bug with PostgreSQL backend?

238 views
Skip to first unread message

Francis Galiegue

unread,
Jul 20, 2015, 4:24:19 AM7/20/15
to sona...@googlegroups.com
Hello,

This is the environment:

* Debian Jessie;
* PostgreSQL 9.4;
* SonarQube 5.1.1.

I ran an analysis on a project which is not small (more than 800k lines of code) and failed to set a measure; the problem is that I don't know which measure it is, the stack trace on the sonar runner side does not tell, and there is nothing in sonar.log...

Stack trace:

----
09:39:12.998 INFO  - Store results in database
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 1:22:42.539s
Final Memory: 32M/1471M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
org.sonar.runner.impl.RunnerException: Unable to execute Sonar
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
at java.security.AccessController.doPrivileged(Native Method)
at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
at org.sonar.runner.api.Runner.execute(Runner.java:100)
at org.sonar.runner.Main.executeTask(Main.java:70)
at org.sonar.runner.Main.execute(Main.java:59)
at org.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.IllegalStateException: Unable to save some measures
at org.sonar.batch.index.MeasurePersister.persist(MeasurePersister.java:78)
at org.sonar.batch.phases.DatabaseModePhaseExecutor.executePersisters(DatabaseModePhaseExecutor.java:165)
at org.sonar.batch.phases.DatabaseModePhaseExecutor.execute(DatabaseModePhaseExecutor.java:133)
at org.sonar.batch.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:264)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
at org.sonar.batch.scan.ProjectScanContainer.scan(ProjectScanContainer.java:235)
at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:230)
at org.sonar.batch.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:220)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:57)
at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:45)
at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:135)
at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
at org.sonar.batch.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:158)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:95)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
... 9 more
Caused by: org.apache.ibatis.exceptions.PersistenceException: 
### Error committing transaction.  Cause: org.apache.ibatis.executor.BatchExecutorException: org.sonar.api.database.model.MeasureMapper.insert (batch index #1) failed. Cause: java.sql.BatchUpdateException: Batch entry 45 INSERT INTO project_measures (
      value, metric_id, snapshot_id, rule_id, text_value, tendency,
      project_id, alert_status, alert_text, url, description, rule_priority, characteristic_id, variation_value_1,
      variation_value_2, variation_value_3, variation_value_4, variation_value_5, person_id, measure_data)
    VALUES (
      4.8333909955782E12, 269, 171618, NULL, NULL, NULL,
      NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL, NULL
    ) was aborted.  Call getNextException to see the cause.
### Cause: org.apache.ibatis.executor.BatchExecutorException: org.sonar.api.database.model.MeasureMapper.insert (batch index #1) failed. Cause: java.sql.BatchUpdateException: Batch entry 45 INSERT INTO project_measures (
      value, metric_id, snapshot_id, rule_id, text_value, tendency,
      project_id, alert_status, alert_text, url, description, rule_priority, characteristic_id, variation_value_1,
      variation_value_2, variation_value_3, variation_value_4, variation_value_5, person_id, measure_data)
    VALUES (
      4.8333909955782E12, 269, 171618, NULL, NULL, NULL,
      NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL, NULL
    ) was aborted.  Call getNextException to see the cause.
at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:26)
at org.apache.ibatis.session.defaults.DefaultSqlSession.commit(DefaultSqlSession.java:177)
at org.apache.ibatis.session.defaults.DefaultSqlSession.commit(DefaultSqlSession.java:169)
at org.sonar.core.persistence.DbSession.commit(DbSession.java:61)
at org.sonar.core.persistence.BatchSession.commit(BatchSession.java:177)
at org.sonar.core.persistence.BatchSession.increment(BatchSession.java:214)
at org.sonar.core.persistence.BatchSession.insert(BatchSession.java:134)
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:51)
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:52)
at com.sun.proxy.$Proxy78.insert(Unknown Source)
at org.sonar.batch.index.MeasurePersister.persist(MeasurePersister.java:72)
... 33 more
Caused by: org.apache.ibatis.executor.BatchExecutorException: org.sonar.api.database.model.MeasureMapper.insert (batch index #1) failed. Cause: java.sql.BatchUpdateException: Batch entry 45 INSERT INTO project_measures (
      value, metric_id, snapshot_id, rule_id, text_value, tendency,
      project_id, alert_status, alert_text, url, description, rule_priority, characteristic_id, variation_value_1,
      variation_value_2, variation_value_3, variation_value_4, variation_value_5, person_id, measure_data)
    VALUES (
      4.8333909955782E12, 269, 171618, NULL, NULL, NULL,
      NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL, NULL
    ) was aborted.  Call getNextException to see the cause.
at org.apache.ibatis.executor.BatchExecutor.doFlushStatements(BatchExecutor.java:127)
at org.apache.ibatis.executor.BaseExecutor.flushStatements(BaseExecutor.java:114)
at org.apache.ibatis.executor.BaseExecutor.flushStatements(BaseExecutor.java:109)
at org.apache.ibatis.executor.BaseExecutor.commit(BaseExecutor.java:201)
at org.apache.ibatis.executor.CachingExecutor.commit(CachingExecutor.java:104)
at org.apache.ibatis.session.defaults.DefaultSqlSession.commit(DefaultSqlSession.java:174)
... 42 more
Caused by: java.sql.BatchUpdateException: Batch entry 45 INSERT INTO project_measures (
      value, metric_id, snapshot_id, rule_id, text_value, tendency,
      project_id, alert_status, alert_text, url, description, rule_priority, characteristic_id, variation_value_1,
      variation_value_2, variation_value_3, variation_value_4, variation_value_5, person_id, measure_data)
    VALUES (
      4.8333909955782E12, 269, 171618, NULL, NULL, NULL,
      NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL,
      NULL, NULL, NULL, NULL, NULL, NULL
    ) was aborted.  Call getNextException to see the cause.
at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2743)
at org.postgresql.core.v3.QueryExecutorImpl$1.handleError(QueryExecutorImpl.java:461)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1928)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:405)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2892)
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
at org.apache.ibatis.executor.BatchExecutor.doFlushStatements(BatchExecutor.java:103)
... 47 more
----

The only hint I have is looking into the postgresql logs, which say:

----
2015-07-20 09:39:19 CEST [28206-1] sonar@sonardb ERROR:  numeric field overflow
2015-07-20 09:39:19 CEST [28206-2] sonar@sonardb DETAIL:  A field with precision 30, scale 20 must round to an absolute value less than 10^10.
2015-07-20 09:39:19 CEST [28206-3] sonar@sonardb STATEMENT:  INSERT INTO project_measures (
              value, metric_id, snapshot_id, rule_id, text_value, tendency,
              project_id, alert_status, alert_text, url, description, rule_priority, characteristic_id, variation_value_1,
              variation_value_2, variation_value_3, variation_value_4, variation_value_5, person_id, measure_data)
            VALUES (
              $1, $2, $3, $4, $5, $6,
              $7, $8, $9,
              $10, $11, $12, $13, $14,
              $15, $16, $17, $18, $19, $20
            )
2015-07-20 09:39:19 CEST [28207-1] sonar@sonardb LOG:  unexpected EOF on client connection with an open transaction
----

Is that a bug in the schema, something else?

Regards,

Francis Galiegue

unread,
Jul 20, 2015, 5:50:53 AM7/20/15
to sona...@googlegroups.com
OK, so it seems to be indeed a bug with the PostgreSQL usage of SonarQube.

This message is the key, in fact:


2015-07-20 09:39:19 CEST [28206-2] sonar@sonardb DETAIL:  A field with precision 30, scale 20 must round to an absolute value less than 10^10.

This indeed only allows for 10 digits before the decimal separator.

Well, I can alter table as a temporary workaround, but it'd be nice if the next version of SonarQube allowed for larger numbers... The halstead volume of a million line project is pretty large :p

Simon Brandhof

unread,
Jul 20, 2015, 6:32:46 AM7/20/15
to Francis Galiegue, sona...@googlegroups.com
Hi Francis,

Thanks for the feedback. Indeed the decimal type of database is not enough for large numbers. 
The JIRA ticket already exists here : http://jira.sonarsource.com/browse/SONAR-6710.

Regards


Simon BRANDHOF | SonarSource
Tech Lead & Co-Founder
http://twitter.com/SimonBrandhof

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/be966d18-ebbc-42b9-b6e7-c0dbb315b4f0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Francis Galiegue

unread,
Jul 20, 2015, 6:39:20 AM7/20/15
to sona...@googlegroups.com, fgal...@gmail.com
Hello again,


On Monday, July 20, 2015 at 12:32:46 PM UTC+2, Simon Brandhof wrote:
Hi Francis,

Thanks for the feedback. Indeed the decimal type of database is not enough for large numbers. 
The JIRA ticket already exists here : http://jira.sonarsource.com/browse/SONAR-6710.

Regards


Uhm, OK, I have just read the ticket; there's something I don't get here: the ticket seems to imply that this same column is also used to store any Double measure, is this the case? A double can far exceed Integer.MAX_VALUE in its mantissa alone...

(while we're at it, side question: is there a possibility to create Metric.ValueType.LONG? The WORK_DUR value type does specify Long.class as a serializable class, so it should be doable...)

Regards, 

Simon Brandhof

unread,
Jul 20, 2015, 6:46:39 AM7/20/15
to Francis Galiegue, sona...@googlegroups.com

Uhm, OK, I have just read the ticket; there's something I don't get here: the ticket seems to imply that this same column is also used to store any Double measure, is this the case? A double can far exceed Integer.MAX_VALUE in its mantissa alone...

The problem is not about java doubles, but about the decimal type as configured in db.
 

(while we're at it, side question: is there a possibility to create Metric.ValueType.LONG? The WORK_DUR value type does specify Long.class as a serializable class, so it should be doable...)

In fact we'd like to define a single type for integers. It will be implemented as java long. 

Francis Galiegue

unread,
Jul 20, 2015, 7:21:30 AM7/20/15
to sona...@googlegroups.com, fgal...@gmail.com
Hello again,


On Monday, July 20, 2015 at 12:46:39 PM UTC+2, Simon Brandhof wrote:

Uhm, OK, I have just read the ticket; there's something I don't get here: the ticket seems to imply that this same column is also used to store any Double measure, is this the case? A double can far exceed Integer.MAX_VALUE in its mantissa alone...

The problem is not about java doubles, but about the decimal type as configured in db.
 

OK, thanks for the information. I haven't delved into the code that deep yet...

 

(while we're at it, side question: is there a possibility to create Metric.ValueType.LONG? The WORK_DUR value type does specify Long.class as a serializable class, so it should be doable...)

In fact we'd like to define a single type for integers. It will be implemented as java long. 

That would indeed be nice...

Last question on the subject: right now I have updated the column "value" of table "project_metrics" by hand; will this cause a conflict when I upgrade SonarQube? (I updated it from 30, 20 to 40,20)

Thank you for your time!

Regards, 

Simon Brandhof

unread,
Jul 20, 2015, 7:35:44 AM7/20/15
to Francis Galiegue, sona...@googlegroups.com

Last question on the subject: right now I have updated the column "value" of table "project_metrics" by hand; will this cause a conflict when I upgrade SonarQube? (I updated it from 30, 20 to 40,20)


In the current state, no, it won't cause conflicts. Types of columns are not verified at runtime yet (but there's a ticket for that !). Of course nothing can be guaranteed for future versions.
Reply all
Reply to author
Forward
0 new messages