SonarQube 5.3 后台任务失败,没有登录仪表板 [英] SonarQube 5.3 Background Task Fails with No Log in Dashboard

查看:16
本文介绍了SonarQube 5.3 后台任务失败,没有登录仪表板的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道这类似于 sonarqube 5.2 背景任务有时会在没有日志的情况下失败 - 但是我无法评论(由于缺乏声誉点)以添加更多信息,因此尝试添加此帖子作为答案,但已被版主删除...p>

我在使用 SonarQube 5.2 时遇到问题,昨天升级后现在是 5.3.我已尝试在服务器上将日志记录提高到 TRACE,并在项目本身上启用 sonar.verbose=true.

但是,maven 构建的输出中没有额外的信息 - 只是正常的:

分析成功,您可以在构建日志中浏览xxx.

我确实看到了一个 POST /api/ce/submit?projectKey=xxxx&projectName=yyyy |服务器日志文件中的 time=757ms - 但仅此而已.

我还在 datace eports 中看到一个 zip 文件,其名称与构建日志中的 id 匹配(例如:AVI19fDPpe3MLWoccJn9.zip)

但是 - 我在后台任务屏幕上遇到间歇性故障 - 在后台任务屏幕中没有日志链接,并且在 datacelogs eports 目录中没有创建日志.

我求助于从头开始为 5.3 重新构建 sonarqube 数据库(因为我们没有任何历史记录) - 错误仍在发生.

我正在使用:

  • 全新 sonarqube 5.3 上的 Oracle DB 安装
  • 插件:
    • sonar-java-plugin-3.9
    • sonar-ldap-plugin-1.5.1
    • sonar-scm-perforce-plugin-1.3(虽然目前有 sonar.scm.disabled=true,因为我们在之前的版本中遇到了问题)
    • sonar-csharp-plugin-4.3(与此 java 分析无关)
    • sonar-scm-git-plugin-1.1(与本次分析无关)
    • sonar-scm-svn-plugin-1.2(与本次分析无关)
  • 我正在使用 sonar-jacoco-listeners v 3.2 构建一个 Maven 项目(也尝试过 2.9.1)

解决方案

你遇到了一个很奇怪的问题.

总结一下:

  • 不时
  • 处理后台任务,sonar.log 中没有任何日志,data/ce/logs 目录中也没有任务日志
  • 任务失败(在 SQ 的 UI 中可见)
  • 它运行了很短的时间
  • 报告 zip 文件仍存在于数据目录中

我们唯一一次遇到这样的情况,结果是两个 SonarQube 实例在同一个数据库上运行,这是发生了什么:

  • SQ A(您知道和监控的那个)接收报告,将 zip 文件保存到其数据目录并在数据库中添加一个条目(后台任务)
  • SQ A 和 SQ B 都定期轮询数据库以查找待处理的项目.有时,SQ B 将是第一个从数据库中选择条目并开始处理它的人.由于报告不在其数据目录中,因此处理很快就会失败,并且该条目在数据库中被标记为失败
  • SQ A 从不尝试处理条目,因为从它的角度来看,它要么是 PROCESSING(当 SQ B 正在处理它时),要么是 FAILED(当 SQ B 完成它时).只能处理 PENDING 项.因此,SQ A 的 sonar.log 中不会出现任何日志,也不会创建任务日志.尽管如此,在 UI 中,后台任务仍显示为失败,因为 UI 显示来自 DB 的信息.

SQ A 没有完成处理(即 DB 中条目的状态更改)的一个很好的提示是,报告 zip 文件仍然存在于数据目录中.条目的状态更改为 FAIL 或 SUCCESS 与 zip 文件的删除紧密相关.

这只是一个提示,因为删除也可能失败,但在这种情况下,日志中会出现错误.

I know this is similar to sonarqube 5.2 background tasks sometimes fail with no log - however I cannot comment (due to lack of reputation points) to add some more information, so tried adding this post as an answer, but had it deleted by the moderators...

I was having a problem with SonarQube 5.2, and now 5.3 following an upgrade yesterday. I have tried upping the logging to TRACE on the server, and enabling sonar.verbose=true on the project itself.

However, there is no extra information in the output from the maven build - just the normal:

ANALYSIS SUCCESSFUL, you can browse xxx in the build logs.

I do see a POST /api/ce/submit?projectKey=xxxx&projectName=yyyy | time=757ms in the server log files - but nothing further.

I also see a zip file in datace eports with a name matches the id in build log (eg: AVI19fDPpe3MLWoccJn9.zip)

However - I get intermittent failures on the background tasks screen - with no log link in the background tasks screen, and no logs in datacelogs eports directory created.

I resorted to re-building the sonarqube database from scratch for 5.3 (as we had no history anyway) - and the error was still happening.

I am using:

  • Oracle DB on a fresh sonarqube 5.3 install
  • Plugins:
    • sonar-java-plugin-3.9
    • sonar-ldap-plugin-1.5.1
    • sonar-scm-perforce-plugin-1.3 (although currently have sonar.scm.disabled=true as we had problems in the previous version)
    • sonar-csharp-plugin-4.3 (not relevant for this java analysis)
    • sonar-scm-git-plugin-1.1 (not relevant for this analysis)
    • sonar-scm-svn-plugin-1.2 (not relevant for this analysis)
  • I'm building a Maven project using sonar-jacoco-listeners v 3.2 (have also tried 2.9.1)

解决方案

You are facing a very odd issue.

To sum it up:

  • from time to times
  • a background task is processed without any log in sonar.log nor a task log in the data/ce/logs directory
  • the task failed (as visible in the UI of SQ)
  • it ran for a very short time
  • the report zip file is still present in the data directory

The only time we faced such a scenario, it turned out two SonarQube instances were running on the same database and here is what was going on:

  • SQ A (the one you are aware of and monitoring) receives the report, save the zip file to its data directory and adds an entry (a background task) in the DB
  • SQ A and SQ B both poll the DB regularly for PENDING items to process. Sometimes, SQ B will be the first one to pick the entry from the DB and starts processing it. Since the report is not in its data directory, the processing very quickly fails and the entry is flagged as failed in the DB
  • SQ A never tries to process the entry, because from its point of view, it is either PROCESSING (when SQ B is working on it) or FAILED (when SQ B is done with it). Only items PENDING can be processed. So, no log ever shows up in SQ A's sonar.log and no task log is created either. Still, in the UI the background task is displayed as failed because the UI shows information from the DB.

A good hint that the processing (ie. change of state of the entry in DB) wasn't done by the SQ A is that the report zip file is still present in the data directory. The change of state of the entry to FAIL or SUCCESS is tightly coupled with the deletion of the zip file.

It's only a hint since the deletion could also have failed, but in such case, you would have a ERROR in the logs.

这篇关于SonarQube 5.3 后台任务失败,没有登录仪表板的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆