Laravel Пользовательская очередь не соблюдает retry_after - PullRequest
0 голосов
/ 22 января 2020

У меня возникли проблемы с пользовательским laravel подключением / очередью. Это конкретное соединение / очередь используется для заданий, которые могут длиться от 5 минут до 10 часов (агрегация больших объемов данных и перестройка данных)

У меня есть имя администратора, определенное как

[program:laravel-worker-extended]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/artisan queue:work --queue=refreshQueue,rebuildQueue --sleep=3 --timeout=86400 --tries=2 --delay=360
autostart=true
autorestart=true
user=root
numprocs=4
redirect_stderr=true
stdout_logfile=/var/www/storage/logs/queue-worker.log

У меня есть соединение с очередью, определенное как:

        'refreshQueue' => [
            'driver' => 'database',
            'table' => 'jobs',
            'queue' => 'refreshQueue',
            'retry_after' => 420,   // Retry after 7 minutes
        ],

Я добавляю задание в очередь с помощью команды через:

AggregateData::dispatch()->onConnection('refreshQueue')->onQueue('refreshQueue');

Когда построено DatabaseQueue, retryAfter равно 420, как определено , однако вот мои журналы заданий:

[2020-01-22 18:25:37] local.INFO: BEGINNING AGGREGATION  
[2020-01-22 18:25:37] local.INFO: Aggregating data  
[2020-01-22 18:27:08] local.INFO: BEGINNING AGGREGATION  
[2020-01-22 18:27:08] local.ALERT: AGGREGATION FAILED: Aggregation in progress 

Почему он продолжает повторяться через 90 секунд, когда я явно говорю ему повторить после 420?

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

[2020-01-22 18:25:37] local.INFO: BEGINNING AGGREGATION  
[2020-01-22 18:25:37] local.INFO: Aggregating data  
[2020-01-22 18:27:08] local.INFO: BEGINNING AGGREGATION  
[2020-01-22 18:27:08] local.ALERT: AGGREGATION FAILED: Aggregation in progress  
[2020-01-22 18:33:04] local.INFO: [COMPLETE] Aggregating data  
[2020-01-22 18:33:04] local.INFO: Queue job finishedIlluminate\Queue\CallQueuedHandler@call

Я не могу совсем gr asp, почему очередь продолжает Повторите работу через 90 секунд. Я что-то здесь не так делаю?

Редактирование некоторого дополнительного контекста здесь:

Этот метод устанавливает флаг in_progress, когда он начинается, так что он не может быть запущен дважды в одно и то же точное время. , Журналы можно интерпретировать как:

BEGINNING AGGREGATION: первая строка в методе handle() задания

AGGREGATION FAILED: Aggregation in progress: метод failed() задания обрабатывает сбои с помощью исключения , Эта строка показывает, что она одновременно попыталась выполнить задание и обнаружила, что установлен флаг 1, уже означающий, что в данный момент выполняется другое задание. Этот флаг сбрасывается в 0, когда задание завершено или возникла другая исключительная ситуация (не в процессе).

Queue job finishedIlluminate\Queue\CallQueuedHandler@call Добавлена ​​ли дополнительная отладка в сервис-провайдере для прослушивания событий завершения очереди .

Ответы [ 2 ]

0 голосов
/ 23 января 2020

Я понял проблему здесь. В queue.php я определял соединение refreshQueue. Тем не менее, в моем conf супервизора я использовал:

command=php /var/www/artisan queue:work --queue=refreshQueue,rebuildQueue --sleep=3 --timeout=86400 --tries=2 --delay=360

в качестве команды (--queue), где команда должна :

command=php /var/www/artisan queue:work refreshQueue --sleep=3 --timeout=86400 --tries=2 --delay=360

Обратите внимание на отсутствие --queue. Для соединения определен retry_after, а не для самой очереди.

Это важный урок в различии соединений и очередей .

0 голосов
/ 23 января 2020

Это может быть связано с тем, что вы используете тайм-аут. Из документов :

Значение --timeout всегда должно быть как минимум на несколько секунд короче вашего значения конфигурации retry_after. Это гарантирует, что работник, обрабатывающий заданное задание, всегда будет убит до повторного выполнения задания. Если ваш параметр --timeout больше значения конфигурации retry_after, ваши задания могут быть обработаны дважды.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...