Поведение неудачных задач VersionCheck

Разработка
1

Извините, если это не та категория для данного вопроса.

Я оцениваю Discourse, и задача VersionCheck не выполняется в моей среде.

Я заметил, что неудачные задачи накапливаются в Sidekiq и, вероятно, будут перемещены в раздел “dead” после 25 попыток по умолчанию (согласно RubyDoc.info: Class: Sidekiq::JobRetry – Documentation for sidekiq (8.1.2) – RubyDoc.info).

Я понимаю, что мне нужно выяснить причину сбоев, но суть вопроса в следующем: имеет ли смысл хранить эти задачи там? Не лучше ли просто отбрасывать неудачные проверки версий и дождаться следующего выполнения задачи?

На данный момент у меня более 80 задач VersionCheck в очереди на повторную попытку, и это выглядит как пустая трата ресурсов (возможно, небольшой, но всё же трата)…

Судя по моим проверкам, добавление sidekiq_options retry: false в app/jobs/scheduled/version_check.rb решило бы эту проблему.

Не упускаю ли я что-то?

2

Как вы устанавливали? Есть ли основания полагать, что у вас проблемы с сетью? Оперативной памятью?

Возможно, вы правы, но поскольку только вы сообщили об этом (по крайней мере, на данный момент), это не попало в список оптимизаций. Я думаю, что логичнее просто позволить процессу завершиться неудачей после первой попытки.

3

Когда вы последний раз обновляли систему?

Неделю или две назад (в конце октября) возникла проблема с задачей проверки версии, но сейчас она исправлена. Если вы обновите систему через терминал (./launcher rebuild app), всё должно работать корректно.

4

Я использую стандартную установку Docker внутри экземпляра EC2.

Я работаю в корпоративной среде, поэтому между экземпляром и интернетом находится множество брандмауэров, прокси-серверов и средств сканирования безопасности. В логах я вижу ошибку «Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)», поэтому, вероятно, какой-то брандмауэр в какой-то момент блокирует запрос. Я всё ещё изучаю, как Discourse выполняет проверки версий, чтобы я мог воспроизвести их вручную и получить более подробную информацию.

Полностью понимаю. В прошлом я работал с GitLab и сталкивался с множеством проблем, когда полные очереди Sidekiq вызывали снижение производительности и другие странные поведения, поэтому каждый раз, когда я вижу что-то подобное, у меня срабатывает тревога. :smile:

6

Я использую версию 2.8.0.beta9 (959923d3cf)

Да… Обновление через терминал или через графический интерфейс работает нормально (я запускаю его еженедельно). Единственная проблема в данном случае заключается в том, что экран главного администратора не показывает последнюю версию и постоянно сообщает, что я использую устаревшую версию.

7

Тогда вам обязательно нужно выполнить обновление через командную строку.

8

Discourse обращается к интернету для выполнения таких задач, как проверка обновлений версий, получение аватаров пользователей, загрузка удалённых изображений в локальное хранилище и общая функция oneboxing. Если экземпляр отрезан от интернета, действительно возникнут некоторые сбои.

9

Да! Я делаю это каждую неделю, пока не найду решение.

Я отказался от функции oneboxing именно по этой причине. Пока что я не могу разрешить этому серверу полный доступ в интернет.
Доступ к github.com/* уже разрешён, но, вероятно, эта задача проверки версии использует другой URL.

10

Что я бы сделал, так это просто отключил SiteSetting.version_checks, удалил плагин discourse_docker и выполнил обновления через командную строку.

Но в данном случае, если вы можете открыть https://api.discourse.org/api, то, скорее всего, у вас всё в порядке.

11

Спасибо за информацию! У меня получилось, когда я разрешил доступ к https://api.discourse.org/api/version_check.