Php artisan queue work не работает

Laravel очереди не работают

Я использую очереди Laravel для комментирования поста в Facebook. Когда я получаю данные из Facebook Webhook, основываясь на полученных данных, я
комментируя пост. Для обработки 100 ответов одновременно с Facebook webhook я использую очереди Laravel, так что он может выполняться по одному.
Я использовал пошаговый процесс, как указано в https://scotch.io/tutorials/why-laravel-queues-are-awesome

и это моя структура класса работы

использовать InteractsWithQueue, SerializesModels;

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

И это мой логин в laravel.log

Решение

Для использования очереди вы должны немного поработать:

в файле .env вы должны изменить queue_drive с синхронизации на базу данных

после этого вы должны создать таблицу очередей в своей базе данных с помощью команды artisan:

и, наконец, вы должны запустить свою очередь с php artisan queue:listen или же php artisan queue:work

Другие решения

Я вижу, что у вас уже есть таблица очередей.

Попробуйте запустить php artisan queue:listen —tries=3 или же php artisan queue:work и т.п.

Работа с очередями предназначена для выполнения только одного задания на команду. Таким образом, если в таблице 20 заданий, вам может потребоваться запустить очередь 20 раз. Вот почему вы можете бежать queue:listen команда. Но он съедает много процессора.

На сервере вы можете запустить прослушивание очереди с максимум 3 попытками в фоновом режиме.
SSH к вашему серверу в терминале / командной строке. затем CD в каталог вашего проекта, где находится файл ремесленника. Запустите эту команду:

nohup php artisan queue:listen —tries=3 > /dev/null 2>&1 &

В этом случае задания будут автоматически обрабатываться в фоновом режиме. Вам просто нужно отправить работу. И я бы порекомендовал использовать таблицу с ошибками. Если вы используете фоновый список очередей.

Надеюсь это поможет.

Обновление для Laravel 5.7:

В .env , задавать QUEUE_CONNECTION=database так что отправленные задания отправляются в драйвер базы данных.

У меня была такая же проблема, если вы используете laravel 5.7, используйте это в файле .env

после очистки кеша конфигурации вот так

Принятый ответ был проблемой для меня, но я также решил этот вопрос для двух других подобных проблем, которые я решил, и, возможно, они помогут другим людям, которые оказываются здесь.

Другая проблема 1: создание задания (конструктор) работает, но обработчик задания не запускается — Когда-либо.

• Когда-либо является ключевым здесь, потому что, как правило, если ни один из них никогда не срабатывает, то это может быть потому, что ваш код задания изменен и ваша очередь должна быть перезапущена.

Другая проблема 2: создание задания (конструктор) работает, но обработчик задания не запускается — иногда.

• когда иногда верно для вас, то может случиться так, что ваши рабочие места, которые не увольняются, потому что они происходят во время транзакции, как DB::beginTransaction ,

При условии, что я хочу работу, чтобы уволить даже во время транзакции, я могу сделать это:

НО НЕ ДЕЛАЙТЕ ЭТОГО если только ты не хочу уволить свою работу и заставить откат. Моя ситуация уникальна в том, что моя работа отправляет электронные письма об ошибках FATAL, поэтому я хочу, чтобы она сработала, потому что у меня все равно есть ошибка, прерывающая процесс (происходит откат и он незапланирован из-за необработанной ошибки).

Вот ситуация, когда вы не хотели бы делать это:

• Ваша работа отправляет электронное письмо пользователю, когда оплата прошла успешно
• Ваш платеж может быть успешным, не может быть
• в зависимости от успешной оплаты, вы откатываете или делаете коммит

Вы должны структурировать свою рассылку, чтобы она происходила ПОСЛЕ откатки или фиксации
У меня не было такой роскоши для моей работы, потому что это случается, когда я не могу предсказать (фатальная ошибка). Но если у вас есть контроль над ним, например, если вы знаете, что ваш платеж прошел успешно, отправьте его после совершения или выхода из всех уровней транзакций!

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

Источник

Php artisan queue:work not working but job are inserted

I am troubling with php artisan queue::work command.

My command not working but my jobs are inserted into job table but never executing.

I am using mongodb driver for queue.

What I am doing wrong please suggest me.

3 Answers 3

After spending half day on searching I noticed that queues do not run on maintenance mode. You have to put —force at the end of it.

—force Force the worker to run even in maintenance mode

So run php artisan queue:work —force in order to run queues on maintenance mode.

I was having the similar issue. The Jobs were being inserted into jobs table in MySql DB, but php artisan queue:work didn’t pick those up.

In my case the queue was named (queue column value in jobs table) ‘priority’.

So i had to run the queue:work command differently:

But careful that above command only executes jobs in priority queue; You can add more queue names if needed like so —queue=priority,queue_3,queue_4

I was expecting queue:work without —queue= value to pickup any pending jobs.

Turns out, I was wrong. ¯\_(ツ)_/¯

Hope this helps somebody else.

Since this thread is a little bit old, I’ll share my experience of it.

There is an error which is not obvious to find but corresponding to this condition. You can check your table jobs , and in Laravel the jobs should have literally been removed if your queue:work works well, so the problem is that your queue cannot deal with the top job in your table. It may be a problem of serializable data in db.

To solve it, you can try clearing the table jobs and reset the ‘incremental id ‘ from

0 . On the other hand, you can also check your data sequence. This may be helpful after resetting the table.

Источник

Laravel queues not working

I am using laravel queues for commenting on the facebook post. When ever i recieve data from facebook webhook, based on the recieved details i am commenting on the post. To handle 100 responses at once from facebook webhook i am using laravel queues, so that it can execute one by one. I have used the step by step process as mentioned in https://scotch.io/tutorials/why-laravel-queues-are-awesome

and this is my job class structure

use InteractsWithQueue, SerializesModels;

I am hitting webhooks() function continuously, all the jobs are working simultaneously but not in queue, none of the jobs are storing in jobs table, i have given delay but it is also not working, please some one help me, I have been trying from yesterday, but no result.

And this is my log in laravel.log

13 Answers 13

for use queue you should some work :

in .env file you should change queue_driver from sync to database, so open .env and do the follow

after it you should create queue table in your database with artisan command :

and for make sure that no config cached

and finally you should run your queue with php artisan queue:listen or php artisan queue:work

I had the same trouble, if you are using laravel 5.7, use this in .env file

Next, clear config cache like this

In my case, i use custom queue name for group my jobs.

That queue is not executed by:

i need specify queue name (Valid for work and listen):

Update for Laravel 5.7:

In .env , set QUEUE_CONNECTION=database so that dispatched jobs go to the database driver.

Make sure your app is not in maintenance mode. I had mine in maintenance, but allowing my local ip address. I couldn’t figure out why it was not running. I had to finally go debugging the WorkCommand to find out.

The accepted answer was a problem for me, but I also wound up on this question for 2 other similar problems which I solved, and maybe they will help other people that wind up here.

Other problem 1: job creation (constructor) works, but job handler does not fire — ever.

• the ever is key here because, typically, if none of them ever fire, then it could be because your job code is modified and your queue should be restarted.

Other problem 2: job creation (constructor) works, but job handler does not fire — sometimes.

• when sometimes is true for you, then it may be that your jobs that are not firing are because they are happening while in a transaction, like a DB::beginTransaction .

Assuming I want the job to fire even during a transaction, I can do this:

BUT DON’T DO THIS unless you want to fire your job and force rollback. My situation is unique in that my job sends emails on FATAL errors, so I want it to fire because I have an error breaking the process anyway (rollback going to happen and is unplanned due to uncaught error).

Here’s a situation when you wouldn’t want to do this:

• your job sends an email to a user when payment is successful
• your payment could be successful, could not be
• depending on successful payment, you rollback or commit

You should structure your dispatch to happen AFTER you rollback or commit. I did not have that luxury for my job because it happens when I cannot predict (a FATAL error). But if you have control over it, like knowing your payment is successful, dispatch after you have committed, or exited all levels of transactions!

I am not sure of the behavior of triggering a job while in the transaction, and then rolling back or committing. It could be worked around if it didn’t work properly by adding a delay, but that seems unreliable (guessing at how long to wait) unless it was a significant delay.

Источник

Laravel и закон Мерфи. Очереди, задачи и ошибки.

«Всё, что может пойти не так, пойдет не так», — утверждает хорошо известный закон Мерфи. Множество вещей можно отнести к этой популярной поговорке, но особенно нужно его учитывать при разработке ПО: надейтесь на лучшее, но будьте готовым к худшему.

Закон Мерфи и разработка ПО

При разработке программного обеспечения всегда полезно задуматься о том, что делать, если что-то пойдет не так. Особенно при работе с внешними API. Ошибка может даже возникнуть не из-за вашего кода, но — как мы узнали из закона Мерфи — мы должны готовиться к худшему. Внешний API может привести к тайм-ауту, выдать ошибку 503 (превышен лимит скорости), получить критическое изменение в коде… Много чего может пойти не так.

Давайте посмотрим, как можно решить эти проблемы в Laravel.

Инкапсуляция Очереди

При работе с внешним API может оказаться целесообразным разделить вызовы к нему по отдельным процессам. У Laravel есть отличный способ инкапсуляции: Queued Jobs (Задачи в очереди). Очереди имеют несколько преимуществ:

• Процессы асинхронны (происходят в фоновом режиме).
• Они могут автоматически пытаться выполнить задачи несколько раз
• Задачи можно повторить вручную
• Понимание, почему эта конкретная задача не удалась

Основы использования Queued Jobs в Laravel

Задача в Laravel ничем не отличается от простого PHP-класса с методом handle(). Мы указываем, что он должен быть поставлен в очередь, добавляя интерфейс ShouldQueue. Что бы ни происходило в методе handle, оно будет выполнено, когда задача извлечется из очереди.

Мы можем отправить задачу в очередь, используя хелпер dispatch:

Воркер очереди можно запустить при помощи команды artisan queue:work.

В командной строке будет показано, что задача обработана:

Когда что-то идет не так

Как гласит закон Мерфи: всё пойдет не так. Когда задача не выполнилась, то мы видим, что по дефолту Laravel продолжает попытки её выполнить без каких-либо задержек.

Ограничение попыток

Одним из решений этой проблемы является ограничение количества повторных попыток. Самый быстрый способ — указать это в команде artisan.

Теперь, когда очередь попыталась выполнить задачу 3 раза, то она отметит его как проваленное.

Уведомление пользователя о сбое

У Laravel есть способ подключения к проваленным задачам при помощи метода failed() в классе задач. Вы можете использовать этот хук, чтобы уведомить пользователя о сбое, отправить текстовое сообщение о том, что что-то идет не так, и т.д. Хук отработает только после последней попытки.

Повторная попытка выполнения задачи

Laravel может сохранить все проваленные задачи в базе данных. Но, сначала вы должны создать таблицу failed_jobs, выполнив:

Таблица failed_jobs содержит информацию о соединении, очереди, полезной нагрузке и сгенерированном исключении.

Мы можем просмотреть все невыполненные задачи, запустив queue:failed:

Эта команда покажет вам следующее:

Таблица из БД показывает дополнительную информацию, такую как полезная нагрузка и выданные исключения. Это также может быть отображено с помощью Laravel Horizon.

Сохраняя эту информацию, Laravel позволяет нам повторить задачу позже. Это может быть удобно, когда в коде была ошибка. После исправления её мы можем повторить задание, выполнив команду queue:retry.

Задача (с идентификатором 1) будет возвращена обратно в очередь и выполнена воркером.

Автоматизация процесса повтора

Возможно, не всегда необходимо повторять попытки вручную. Внешний API может выдавать тайм-аут или ошибку 503 — в этих ситуациях мы хотим автоматически повторить попытку несколько раз, но с задержкой между попытками.

Отсрочка попыток

Laravel позволяет нам определить глобальную задержку для всех задач, выполняемых одним и тем же воркером, указав параметр —delay:

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

Ситуация со специфическими повторами и задержками

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

Если эти параметры указаны в задачи, то они будет иметь приоритет над значениями, указанным в командной строке.

Экспоненциальная стратегия отсрочки

В ситуациях, подобных ошибке 503 у внешнего API, может потребоваться увеличить задержку после каждой попытки. Laravel может и это, просто нужно указать метод retryAfter() в классе задач. Через трейт InteractsWithQueue мы можем получить количество попыток.

Приведенный выше пример увеличит задержку при помощи линейной кривой. Если мы хотим реализовать экспоненциальный подход, то можем использовать формулу экспоненциальной отсрочки:

В Laravel это реализуется следующим образом:

Теперь время повтора будет расти экспоненциально, пока не будет достигнуто максимальное количество попыток, как показано на этой диаграмме:

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

Заключение

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

Наш Телеграм-канал — следите за новостями о Laravel.

Задать вопросы по урокам можно на нашем форуме.

Источник