【问题标题】:Sonarqube 6.7 compute engine errorsSonarqube 6.7 计算引擎错误
【发布时间】:2018-05-06 11:55:55
【问题描述】:

有人知道这件事吗?

“目录尚未设置” - 不知道这是什么意思,其他项目工作正常,这个相当大,看 13,500 个 java 文件,另外 2500 个其他文件。构建服务器上的分析完成得很好,但是 web 服务器上的 CE 遇到了这个项目的问题。

较小的项目没有问题。

另外,有谁知道我如何在服务器上重新运行此任务,而无需再次进行一整小时的声纳运行?

2017.11.22 09:43:03 INFO ce[][o.s.ce.app.CeServer] Compute Engine 正在运行 2017.11.22 10:17:07 INFO ce[AV_kFoAKPGI1NQcqJopo][o.s.c.t.CeWorkerImpl] 执行任务 |项目=large_java_project |类型=报告 | id=AV_kFoAKPGI1NQcqJopo |提交者=gbizeau 2017.11.22 10:17:07 错误 ce[AV_kFoAKPGI1NQcqJopo][o.s.s.c.t.s.ComputationStepExecutor] 侦听器执行失败 java.lang.IllegalStateException:目录尚未设置 在 org.sonar.server.computation.task.projectanalysis.batch.BatchReportDirectoryHolderImpl.getDirectory(BatchReportDirectoryHolderImpl.java:37) 在 org.sonar.server.computation.task.projectanalysis.batch.BatchReportReaderImpl.ensureInitialized(BatchReportReaderImpl.java:53) 在 org.sonar.server.computation.task.projectanalysis.batch.BatchReportReaderImpl.readContextProperties(BatchReportReaderImpl.java:222) 在 org.sonar.server.computation.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.createProjectAnalysis(PostProjectAnalysisTasksExecutor.java:123) 在 org.sonar.server.computation.task.projectanalysis.api.posttask.PostProjectAnalysisTasksExecutor.finished(PostProjectAnalysisTasksExecutor.java:103) 在 org.sonar.server.computation.task.step.ComputationStepExecutor.executeListener(ComputationStepExecutor.java:71) 在 org.sonar.server.computation.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:56) 在 org.sonar.server.computation.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:73) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.executeTask(CeWorkerImpl.java:134) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:97) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.withCustomizedThreadName(CeWorkerImpl.java:81) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:73) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:43) 在 java.util.concurrent.FutureTask.run(FutureTask.java:266) 在 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 在 java.util.concurrent.FutureTask.run(FutureTask.java:266) 在 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) 在 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 在 java.lang.Thread.run(Thread.java:748) 2017.11.22 10:17:07 错误 ce[AV_kFoAKPGI1NQcqJopo][o.s.c.t.CeWorkerImpl] 无法执行任务 AV_kFoAKPGI1NQcqJopo

其他错误...

java.lang.IllegalStateException:无法选择 CE 任务 AV_kFoAKPGI1NQcqJopo 的数据 在 org.sonar.db.ce.CeTaskInputDao.selectData(CeTaskInputDao.java:74) 在 org.sonar.server.computation.task.projectanalysis.step.ExtractReportStep.execute(ExtractReportStep.java:59) 在 org.sonar.server.computation.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:64) 在 org.sonar.server.computation.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:52) 在 org.sonar.server.computation.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:73) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.executeTask(CeWorkerImpl.java:134) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:97) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.withCustomizedThreadName(CeWorkerImpl.java:81) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:73) 在 org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:43) 在 java.util.concurrent.FutureTask.run(FutureTask.java:266) 在 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 在 java.util.concurrent.FutureTask.run(FutureTask.java:266) 在 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) 在 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 在 java.lang.Thread.run(Thread.java:748) 引起:org.postgresql.util.PSQLException: ERROR: invalid memory alloc request size 1315662807 在 org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2476) 在 org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2189) 在 org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300) 在 org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428) 在 org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354) 在 org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169) 在 org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:117) 在 org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) 在 org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) 在 org.sonar.db.ce.CeTaskInputDao.selectData(CeTaskInputDao.java:67) ...省略了17个常用框架

更新:所以到目前为止,我一直无法“调整”postgresql 以处理这些更大的大小。我们的项目是 3GB 未压缩。我发现 2GB 的静态代码不需要在我们的构建文件夹(rpms 等)中并删除它们,SonarQube 现在可以运行。虽然这不能解决问题,但我希望其他人可以使用此信息遇到同样的问题。

【问题讨论】:

  • 您使用什么操作系统?也许你有目录路径长度问题。
  • Linux Centos 7,扫描比较大,压缩后有637MB...不知道是无法解压还是解压后才启动?
  • 也许你可以在SonarQube source code的代码扫描过程中找到一些东西
  • 如果您检查ce.log,您是否看到任何其他异常?该错误是由于在处理报告的早期阶段,它未能在内部设置解压缩目录的路径。
  • 我更新了我可以看到的与此扫描失败相关的所有数据。在此之前日志中的任何其他内容都是成功扫描。

标签: java postgresql sonarqube


【解决方案1】:

恐怕您报告的堆栈跟踪隐藏了另一个错误,这将是真正的问题。

在构建参数以调用 Compute Engine 中的公共 PostTask API 时发生报告的错误。您可以查看这段代码,就像在 finally 块中执行一样。我已经开了一张票来解决这个隐藏问题SONAR-10115

但是,该错误确实间接证实了提取报告存在问题。我们“只是”不知道到底是哪一个。我们可以假设它与报告的大小有关。

从数据库中提取报告的 ZIP 文件并流式提取到磁盘。

以下是一些可能出错的想法:

  • 您的数据库无法将整个文件(超时或其他)流式传输到服务器
  • 提取到磁盘失败,因为可用空间不足(取决于数据库供应商和配置、网络...)
  • 或达到文件和/或目录数量的限制(取决于操作系统)
  • 流式传输未按预期工作,并引发了 OOM

【讨论】:

  • 仔细查看日志...我在原始帖子中添加了更多内容,这是否说明了更多信息?另外,我的文件信息是... INFO:分析报告在 145909 毫秒内生成,目录大小 = 3 GB 信息:分析报告在 183709 毫秒内压缩,zip 大小 = 627 MB 信息:分析报告在 83625 毫秒内上传
  • 它确认了我提供的提示之一,数据库存在问题。但是,我在这里帮不上什么忙。我只建议你用谷歌搜索 postgres 错误,让我们知道它是怎么回事。
  • 所以到目前为止我一直无法“调整”postgresql 以处理这些更大的大小。我们的项目是 3GB 未压缩。我发现 2GB 的静态代码不需要在我们的构建文件夹(rpms 等)中并删除它们,SonarQube 现在可以运行了。虽然这不是解决问题的方法,但我希望其他人可以使用此信息遇到同样的问题。
猜你喜欢
  • 2018-05-20
  • 2018-05-13
  • 2019-01-24
  • 1970-01-01
  • 1970-01-01
  • 2015-08-28
  • 1970-01-01
  • 1970-01-01
  • 2016-03-02
相关资源
最近更新 更多