SonarQube 5.3 Zadanie w tle zerwane bez zalogowania Panel kontrolny

Question

Wiem, że jest podobny do sonarqube 5.2 background tasks sometimes fail with no log - jednak nie mogę komentować (z powodu braku punktów reputacji), aby dodać więcej informacji, dlatego próbowałem dodać ten wpis jako odpowiedź, ale został usunięty przez moderatorów ...

Wystąpił problem z SonarQube 5.2, a teraz 5.3 po uaktualnieniu wczoraj. Próbowałem upping logowania do TRACE na serwerze i włączając sonar.verbose = true na samym projekcie.

Jednak nie ma dodatkowych informacji w wyjściu z kompilacji maven - po prostu normalny:

ANALIZA sukces, można przeglądać xxx w dziennikach kompilacji.

Widzę POST /api/ce/submit?projectKey=xxxx&projectName=yyyy | time=757ms w plikach dziennika serwera - ale nic więcej.

widzę też plik zip w data\ce\reports z nazwą odpowiada ID w dzienniku budowy (np AVI19fDPpe3MLWoccJn9.zip)

jednak - mam sporadyczne awarie na ekranie Zadania tle - bez linku dziennika w ekran zadań w tle i nie utworzono żadnych katalogów w katalogu data\ce\logs\reports.

Oparłem się na ponownym budowaniu bazy danych sonarqube od zera na 5,3 (ponieważ i tak nie mieliśmy historii) - a błąd wciąż się zdarzał.

Używam:

• Oracle DB na świeżym sonarqube 5.3 zainstalować
• wtyczki:
  • sonar-java-plugin-3,9
  • sonar-ldap-plugin-1.5.1
  • sonar-scm-perforce-plugin-1.3 (choć obecnie mamy sonar.scm.disabled=true, ponieważ mieliśmy problemy w poprzedniej wersji)
  • sonaru-CSharp-plug-4.3 (nie ma znaczenia dla tego badania Java)
  • sonaru, SCM-git wtyczki-1.1 (nie ma znaczenia dla tego badania)
  • sonaru, SCM-svn-plug-1.2 (Nie istotne dla niniejszej analizy)
• buduję projekt Maven korzystając sonar-jacoco-listeners v 3.2 (próbowałem również 2.9.1)

Answer 1

stoją bardzo dziwny problem.

Podsumowując:

• od czasu do czasu
• zadanie tła jest przetwarzany bez zalogowaniu sonaru.log ani dziennika zadanie w katalogu
• data/ce/logs zadanie nie powiodło się (jak widać w interfejsie SQ)
• biegła przez bardzo krótki czas
• raport pliku zip jest nadal obecny w katalogu danych

tylko raz mamy do czynienia z takim scenariuszem, okazało się dwie instancje SonarQube zostały uruchomione na tej samej bazie danych i oto co się dzieje:

• SQ a (jeden jesteś świadomy oraz ste g) odbiera raport, zapisuje plik zip w swoim katalogu danych i dodaje wpis (zadanie w tle) w DB
• SQ A i SQ B zarówno odpytują DB regularnie o PADANIE przedmiotów do przetworzenia. Czasami SQ B będzie pierwszym, który wybierze wpis z DB i rozpocznie jego przetwarzanie. Ponieważ raport nie znajduje się w katalogu danych, przetwarzanie bardzo szybko kończy się niepowodzeniem, a wpis jest oznaczony jako nieudany w DB
• . SQ A nigdy nie próbuje przetworzyć wpisu, ponieważ z jego punktu widzenia jest to PRZETWARZANIE (gdy SQ B pracuje nad tym) lub FAILED (gdy SQ B jest z nim zrobione). Przetwarzane mogą być tylko elementy OCZEKUJĄCE. W związku z tym w dzienniku sonaru SQ A nie pojawia się żaden log i nie jest tworzony również dziennik zadań. Jednak w interfejsie użytkownika zadanie w tle jest wyświetlane jako nieudane, ponieważ interfejs użytkownika pokazuje informacje z bazy danych.

Dobra wskazówka, że ​​przetwarzanie (tj. Zmiana stanu wpisu w DB) nie została wykonana przez SQ A, to że plik zip raportu jest nadal obecny w katalogu danych. Zmiana stanu wejścia na FAIL lub SUCCESS jest ściśle powiązana z usunięciem pliku zip.

To tylko wskazówka, ponieważ usunięcie mogło również zakończyć się niepowodzeniem, ale w takim przypadku w dziennikach pojawiłby się BŁĄD.