Плагин SonarQube Eclipse: время ожидания при синхронизации
У нас есть довольно раздражающая проблема в нашей настройке SonarQube.
Настройка
На сервере у нас запущена установка SQ 4.5.5. Мы используем плагин SonarQube Eclipse для интеграции функциональности Sonar в IDE. В настоящее время мы используем версию 3.4 плагина SQ eclipse.
Проблема
Когда мы пытаемся синхронизировать проблемы сонара для любого из наших плагинов затмения, это занимает несколько минут, и появляется диалоговое окно на скриншоте ниже.
Файл.log в рабочей области eclipse показывает время ожидания при запросе сервера SonarQube на наличие проблем. Если я открою URL-адрес в браузере, загрузка страницы займет довольно много времени, но в конечном итоге она отобразит данные в формате JSON о наших проблемах с сонаром. Таким образом, это явно похоже на проблему с сервером - наш сервер просто медленен, чтобы получить данные вовремя.
!ENTRY org.sonar.ide.eclipse.core 4 4 2016-04-01 08:24:35.561
!MESSAGE Error during issue query org.sonar.wsclient.issue.IssueQuery@f3d040
!STACK 0
org.sonar.ide.eclipse.wsclient.SonarWSClientException: Error during issue query org.sonar.wsclient.issue.IssueQuery@f3d040
at org.sonar.ide.eclipse.wsclient.internal.SonarWSClientFacade.findIssues(SonarWSClientFacade.java:199)
at org.sonar.ide.eclipse.wsclient.internal.SonarWSClientFacade.getUnresolvedRemoteIssuesRecursively(SonarWSClientFacade.java:174)
at org.sonar.ide.eclipse.core.internal.remote.RemoteSourceCode.getRemoteIssuesRecursively(RemoteSourceCode.java:102)
at org.sonar.ide.eclipse.core.internal.jobs.SynchronizeAllIssuesJob.doRefreshIssues(SynchronizeAllIssuesJob.java:138)
at org.sonar.ide.eclipse.core.internal.jobs.SynchronizeAllIssuesJob.fetchRemoteIssues(SynchronizeAllIssuesJob.java:127)
at org.sonar.ide.eclipse.core.internal.jobs.SynchronizeAllIssuesJob.run(SynchronizeAllIssuesJob.java:78)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.IllegalStateException: Fail to request http://AcmeSonarServer:8080/sonar/api/issues/search?resolved=false&pageSize=-1&componentRoots=ACME.Test.All:acmeTests&pageIndex=1
at org.sonar.wsclient.internal.HttpRequestFactory.execute(HttpRequestFactory.java:156)
at org.sonar.wsclient.internal.HttpRequestFactory.get(HttpRequestFactory.java:129)
at org.sonar.wsclient.issue.internal.DefaultIssueClient.find(DefaultIssueClient.java:49)
at org.sonar.ide.eclipse.wsclient.internal.SonarWSClientFacade.findIssues(SonarWSClientFacade.java:195)
... 6 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at org.sonar.wsclient.kevinsawicki.HttpRequest.code(HttpRequest.java:1481)
at org.sonar.wsclient.internal.HttpRequestFactory.isSuccess(HttpRequestFactory.java:161)
at org.sonar.wsclient.internal.HttpRequestFactory.execute(HttpRequestFactory.java:149)
... 9 more
Эта проблема сохраняется в любой протестированной нами версии Eclipse (Индиго, Луна, Марс). Единственный найденный нами обходной путь - установить плагин SonarQube в версии 3.5 и установить флажок " Принудительный предварительный просмотр" вместо инкрементального анализа. Однако проверка опции в версии 3.4 плагина eclipse не помогает.
Почему бы вам просто не обновить плагин?
Кажется довольно очевидным, что мы должны просто обновить наш плагин eclipse, чтобы снова иметь рабочую среду, но версия 3.5 требует Java 1.7. На данный момент мы все еще работаем со старой версией 1.6, и мы просто не можем так легко ее обновить в текущей среде.
Помимо этого, проблема по-прежнему относится к плагину 3.5, если не установлен флажок Принудительный предварительный просмотр вместо инкрементального анализа. Таким образом, это означает, что ошибка воспроизводима несколькими версиями Eclipse и несколькими версиями плагинов.
После нескольких месяцев работы с SQ 4.5.5 и плагином eclipse 3.4 мы просто не знаем, что может быть причиной вышеупомянутого поведения тайм-аута.
- Поможет ли обновить наш сервер Sonar Cube до более новой версии?
- Помогут ли здесь действия по поддержке базы данных (реорганизация индексов или что-то в этом роде)?
- Как мы можем настроить сервер так, чтобы он мог доставить ответ вовремя?
Обновить:
Как уже упоминалось в моем ответе ниже, вначале помогла ежедневная перестройка индексов базы данных. Но через несколько дней, даже непосредственно после перестроения индексов, запуск локального анализа Sonar с помощью SonarQube завершится неудачей.
Обновление до SonarQube 4.5.7 тоже не помогло. Итак, в основном, мы вернулись на круги своя.
- Возможно ли, что наш проект гидролокатора слишком велик? Мы отслеживаем нашу разработку программного обеспечения в одном сонарном проекте с>500k LOC.
- Вы рекомендуете обновить до SonarQube 5.x?
1 ответ
Обновить
Восстановление индексов базы данных не решило эту проблему. Пожалуйста, проверьте обновление в оригинальном вопросе.
Оригинальный ответ
Итак, мы наконец разобрались с проблемой, она была вызвана фрагментированными индексами таблиц базы данных. После восстановления индексов запрос URL-адреса, который включен в Stacktrace в исходном вопросе, занимает всего 3 секунды. вместо нескольких минут.
Это происходит каждый раз, когда анализ Sonar запускается и импортирует данные в базу данных. Это происходит один раз в день в нашей настройке, так что теперь мы будем обновлять индексы тоже снова.
Это лучший обходной путь, чем обновление плагина eclipse, но, на мой взгляд, это тоже обходной путь. Анализ SonarCube не должен оставлять сервер в состоянии, в котором до получения списка проблем требуется несколько минут.
Если у кого-то есть лучшее решение этой проблемы, пожалуйста, поделитесь:)