SonarQube 5.3 L'attività in background non riesce con Nessun accesso nel cruscotto

Question

So che è simile a sonarqube 5.2 background tasks sometimes fail with no log - tuttavia non posso commentare (a causa della mancanza di punti reputazione) per aggiungere ulteriori informazioni, quindi ho provato ad aggiungere questo post come risposta, ma avevo cancellato dai moderatori ...

Stavo avendo un problema con SonarQube 5.2 e ora 5.3 dopo un aggiornamento di ieri. Ho provato ad aumentare la registrazione su TRACE sul server e abilitare sonar.verbose = true sul progetto stesso.

Tuttavia, non v'è alcuna informazione supplementare in uscita dalla generazione Maven - solo il normale:

ANALISI successo, è possibile sfogliare xxx nei log di compilazione.

Vedo un POST /api/ce/submit?projectKey=xxxx&projectName=yyyy | time=757ms nei file di registro del server, ma non oltre.

vedo anche un file zip in data\ce\reports con un nome corrisponde all'ID nel log di compilazione (ad esempio: AVI19fDPpe3MLWoccJn9.zip)

Tuttavia - ho guasti intermittenti sullo schermo le operazioni in background - senza alcun collegamento log in schermata delle attività in background e nessun registro nella directory data\ce\logs\reports creata.

Ho ricominciato a ricostruire il database sonarqube da zero per 5.3 (poiché non avevamo comunque alcuna storia) - e l'errore stava ancora accadendo.

sto usando:

• Oracle DB su una nuova sonarqube 5.3 installare
• Plugin:
  • sonar-java-plugin-3,9
  • sonar-ldap-plugin-1.5.1
  • sonar-scm-perforce-plugin-1.3 (anche se attualmente abbiamo sonar.scm.disabled=true come abbiamo avuto problemi nella versione precedente)
  • sonar-csharp-plugin-4.3 (non rilevante per questa analisi java)
  • sonar-SCM-git-plugin-1.1 (non rilevanti per questa analisi)
  • sonar-SCM-svn-plugin-1.2 (non rilevanti per questa analisi)
• sto costruendo un progetto Maven usando sonar-jacoco-listeners v 3.2 (hanno anche cercato 2.9.1)

Answer 1

Siete di fronte un problema molto strano.

Per riassumere:

• di volta in volte
• attività in background viene elaborato senza alcun registro nel sonar.registro, né un registro dell'attività nella data/ce/logs directory
• l'attività non riuscita (come visibile nell'interfaccia utente di SQ)
• ha funzionato per un tempo molto breve file zip
• il rapporto è ancora presente nella directory dei dati

l'unica volta che abbiamo dovuto affrontare un tale scenario, si è scoperto due istanze SonarQube erano in esecuzione sullo stesso database e qui è quello che stava succedendo:

• SQ a (quella che si è consapevoli di e Verifica e Control g) riceve il rapporto, salva il file zip nella sua directory di dati e aggiunge una voce (un'attività in background) nel DB
• SQ A e SQ B eseguono entrambi il polling del DB regolarmente per gli elementi PENDING da elaborare. A volte, SQ B sarà il primo a scegliere la voce dal DB e inizierà l'elaborazione. Poiché il report non si trova nella sua directory dei dati, l'elaborazione fallisce molto rapidamente e la voce viene contrassegnata come non riuscita nel DB
• SQ A non tenta mai di elaborare la voce, perché dal suo punto di vista, è o PROCESSING (quando SQ B sta lavorando su di esso) o FAILED (quando SQ B è fatto con esso). È possibile elaborare solo gli elementi PENDING. Quindi, nessun log si presenta mai nel file sonar.log di SQ A e non viene creato alcun registro attività. Tuttavia, nell'interfaccia utente l'attività in background viene visualizzata come non riuscita perché l'interfaccia utente mostra informazioni dal DB.

Un buon suggerimento che l'elaborazione (cioè cambio di stato della voce in DB) non è stata eseguita dall'SQ A è che il file zip del rapporto è ancora presente nella directory dei dati. Il cambio di stato dell'entrata in FAIL o SUCCESS è strettamente associato alla cancellazione del file zip.

È solo un suggerimento poiché la cancellazione potrebbe anche non essere riuscita, ma in tal caso, si avrebbe un ERRORE nei registri.