Сбой фоновой задачи SonarQube 5.3 без входа в панель мониторинга

Я знаю, что это похоже на фоновые задачи sonarqube 5.2 иногда терпят неудачу без журнала - однако я не могу комментировать (из-за отсутствия очков репутации), чтобы добавить дополнительную информацию, поэтому попытался добавить этот пост в качестве ответа, но модераторы удалили его...

У меня была проблема с SonarQube 5.2, а теперь и с 5.3 после вчерашнего обновления. Я попытался увеличить ведение журнала до TRACE на сервере и включить sonar.verbose=true в самом проекте.

Однако в выводе сборки maven нет дополнительной информации - просто нормально:

АНАЛИЗ УСПЕШЕН, вы можете просмотреть xxx в журналах сборки.

Я вижу POST /api/ce/submit?projectKey=xxxx&projectName=yyyy | time=757ms в файлах журнала сервера, но больше ничего.

Я также вижу zip-файл в data\ce\reports с именем, совпадающим с идентификатором в журнале сборки (например: AVI19fDPpe3MLWoccJn9.zip)

Однако я получаю периодические сбои на экране фоновых задач - без ссылки на журнал на экране фоновых задач и без создания журналов в каталоге data\ce\logs\reports.

Я прибегнул к пересборке базы данных sonarqube с нуля для версии 5.3 (поскольку у нас все равно не было истории) - и ошибка все еще происходила.

Я использую:

  • Oracle DB при новой sonarqube 5.3 установке
  • Plugins:
    • sonar-java-plugin-3.9
    • сонар-ldap-плагин-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 (не относится к данному анализу)
  • Я создаю проект Maven, используя sonar-jacoco-listeners v 3.2 (также пробовал 2.9.1)

sonarqube sonarqube5.2
person Rohan Pynor    schedule 13.01.2016    source источник
comment
Когда вы активируете уровень DEBUG для журналов, можете ли вы скопировать и вставить куда-нибудь (например, pastebin.org) то, что написано в файле logs/sonar.log после запуска анализа?   -  person Fabrice - SonarSource Team    schedule 13.01.2016
comment
Файлы журнала находятся здесь: gist.github.com/rpynor/d35ed08ecab0a40a4d0a   -  person Rohan Pynor    schedule 13.01.2016
comment
Для этого конкретного анализа в data/ce/reports был создан zip-файл с именем AVI6rosFQGlYbPrUc57o.zip, а в data/ce/logs/report не было создано файлов журналов. Кроме того, на панели мониторинга фон отображается как сбой продолжительностью 31 мс без ссылки на файл журнала.   -  person Rohan Pynor    schedule 13.01.2016
comment
Я должен также добавить, для полноты картины, что мы размещаем это на сервере Windows 2008 R2.   -  person Rohan Pynor    schedule 13.01.2016
comment
Это странно, у вас должна быть хотя бы одна строка web[ossctCeWorkerCallableImpl] Execute task в файле sonar.log, если вы говорите, что видите неудачную фоновую задачу... Можете ли вы активировать уровень TRACE для логов и скопировать-вставить это снова?   -  person Fabrice - SonarSource Team    schedule 13.01.2016
comment
Я вижу, что для прогона, который работал ранее, прошлой ночью - 2016.01.13 02:38:35 INFO web[o.s.s.c.t.CeWorkerCallableImpl] Выполнить задачу | проект=com.xxx.xxx.xxx.asf-parent | id=AVI42Vv2MSzbk9eumfw8 2016.01.13 02:50:45 INFO web[o.s.s.c.t.CeWorkerCallableImpl] Выполненная задача | проект=com.xxx.xxx.xxx:asf-parent | идентификатор = AVI42Vv2MSzbk9eumfw8 | время=729848 мс   -  person Rohan Pynor    schedule 13.01.2016
comment
и анализ, который я только что провел, похоже, успешно поставлен в очередь.   -  person Rohan Pynor    schedule 13.01.2016
comment
Был еще один сбой - журнал трассировки находится здесь: gist.github.com/rpynor/e21efd54635006416b51   -  person Rohan Pynor    schedule 13.01.2016
comment
Я обновился до jre1.8.0_51 с 1.7.0_15-b03 (в файле wrapper.conf), и у меня было несколько успешных фоновых запусков. Я позволю ночным сборкам запуститься, чтобы увидеть, имеет ли это значение.   -  person Rohan Pynor    schedule 13.01.2016
comment
Не повезло - по-прежнему возникают периодические сбои - один и тот же проект иногда работает, иногда нет.   -  person Rohan Pynor    schedule 14.01.2016
comment
Можете ли вы убедиться, что у вас нет двух экземпляров SonarQube, указывающих на одну и ту же БД?   -  person Fabrice - SonarSource Team    schedule 14.01.2016
comment
Нет — я дважды проверил — у нас есть только один экземпляр Sonar.   -  person Rohan Pynor    schedule 14.01.2016

Ответы (1)


arrow_upward
11
arrow_downward

Вы столкнулись с очень странной проблемой.

Подвести итог:

  • время от времени
  • фоновая задача обрабатывается без какого-либо журнала в sonar.log или журнала задач в каталоге data/ce/logs
  • задача не удалась (как видно в пользовательском интерфейсе SQ)
  • он работал очень недолго
  • ZIP-файл отчета все еще находится в каталоге данных.

Единственный раз, когда мы столкнулись с таким сценарием, оказалось, что два экземпляра SonarQube работают в одной базе данных, и вот что происходит:

  • SQ A (тот, о котором вы знаете и который вы отслеживаете) получает отчет, сохраняет zip-файл в своем каталоге данных и добавляет запись (фоновую задачу) в БД.
  • SQ A и SQ B регулярно опрашивают БД для обработки элементов PENDING. Иногда SQ B будет первым, кто выберет запись из БД и начнет ее обработку. Поскольку отчет не находится в своем каталоге данных, обработка очень быстро завершается сбоем, и запись помечается как неудавшаяся в БД.
  • SQ A никогда не пытается обработать запись, потому что, с его точки зрения, она находится либо в состоянии PROCESSING (когда над ней работает SQ B), либо в состоянии FAILED (когда SQ B завершает работу с ней). Только элементы PENDING могут быть обработаны. Таким образом, в sonar.log SQ A журнал никогда не отображается, и журнал задач также не создается. Тем не менее, в пользовательском интерфейсе фоновая задача отображается как невыполненная, поскольку в пользовательском интерфейсе отображается информация из БД.

Хороший намек на то, что обработка (т.е. изменение состояния записи в БД) не была выполнена SQ A, заключается в том, что zip-файл отчета все еще присутствует в каталоге данных. Изменение состояния записи на FAIL или SUCCESS тесно связано с удалением zip-файла.

Это всего лишь подсказка, так как удаление тоже могло завершиться неудачей, но в таком случае у вас будет ОШИБКА в логах.

person Seb - SonarSource Team    schedule 15.01.2016
comment
Стыдно, похоже, вы правы. Кто-то еще в организации «позаимствовал» нашу схему оракула для запуска своего собственного экземпляра SonarQube — я выселю их, и, надеюсь, проблема будет решена. - person Rohan Pynor; 15.01.2016
comment
Большое спасибо за этот ответ! Я столкнулся с той же проблемой и не мог представить, что это второй экземпляр SQ. Но после включения ведения журнала подключения к базе данных я обнаружил второй — кто-то клонировал мою виртуальную машину с SQ и забыл изменить подключение к базе данных. Вы спасли меня как минимум от нескольких дней, когда я рвал на себе волосы :D - person Alex; 22.01.2016