I am a newbie with laravel, and I am implementing email verification system with queue in laravel.
What happening is, when I execute php artisan queue:work it works fine, when it needs to triggers, but when I quit the queue and re-execute, it doesn't trigger anymore.
I tried php artisan queue:restart, but it didn't do the trick.
What could be causing this please?
Queue will only work as long as queue:work is still running or executing in console. Any jobs fired after this has stopped will not be executed. You get to see your jobs in the database if you are using database driver as your queue driver . I use Supervisor to keep queue:work running at the backround
Related
I try to dispatch a job on my local dev machine.
I setup my .env and queue config ; QUEUE_CONNECTION=database
I also did the migrate :
php artisan queue:table
php artisan migrate
Then create my job something like : myjob::dispatchNow();
And finally run my worker: php artisan queue:work
With all that the code launch and execute well but not the job. The job is not created in the database jobs table. (nor in faield_jobs
Is I am missing any step?
Do I need something else on my local machine to run jobs queue?
Thanks for any help.
You are using synchronous dispatching by using myjob::dispatchNow(). The database does not need to be involved as it runs the job during the same request and your queue worker never knows about it. It is equivalent to having QUEUE_DRIVER=sync.
If you use myjob::dispatch() before you start the queue worker, you will see the job in your database.
After running the command:
php artisan queue:work
Expected behaviour: that the queue worker will continue to run until stopped or it fails.
Actual behaviour: queue worker stops after every job, regardless if the job fails or completes successfully.
The above is consistent with Laravel 5.2
https://laravel.com/docs/5.2/queues#daemon-queue-worker
However, since I am running Laravel 5.7 I would expect the behaviour described in
https://laravel.com/docs/5.7/queues#running-the-queue-worker
When running a worker in Laravel forge the queue worker seems to restart after every job.
Are there any configurations that I am missing that would explain this behaviour?
NOTE: when the queue worker ends there are no exceptions thrown and
nothing logged. it simply restarts.
You are right, php artisan queue:work should run until stopped manually. The only exceptions are the following options:
--once Only process the next job on the queue
--stop-when-empty Stop when the queue is empty
My guess would be that Laravel forge uses supervisor which restarts background jobs every so often to prevent memory leaks and other failures. For more information about supervisor in laravel see the docs.
Have you tried running it in your development environment to see if it restarts there as well?
I made a Laravel app that uses the queue system (via database) to send emails. These emails are Job instances and are pushed to the queue after a cron-job is complete every 3 minutes or so.
If I run the artisan command
/path_to_php/7.1/bin/php artisan queue:work --queue=emails_1--tries=2 --daemon
in the terminal via SSH, it starts processing the jobs and sending emails. Obviously I would like to run this command and exit the terminal with it still running so I used the "nohup" approach.
nohup /path_to_php/7.1/bin/php artisan queue:work --queue=emails_1--tries=2 --daemon > storage/logs/laravel.log &
After running this I get a PDOException:
PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction in ...
I'm not really familiar with this error as I've never encountered something like this before but why can't I run the queue work command using nohup but can run it without problems without nohup? Any ideas as to why this is happening ? I'm using Laravel 5.2.
Please enlighten me. Thanks a lot.
Don't use the database queue driver in production. Try to avoid using the database queue driver when you're having a large queue, it's recommended that you use something like Redis which doesn't have the deadlock problems a database-based driver has.
Do you have additional info at Laravel Github: https://github.com/laravel/framework/issues/19242#issuecomment-302505260
I'm using sqs queue in my laravel. Right now I have successsfully pushed my queue job to sqs server as shown in the picture below :
The problem is, the message is never got executed. So how to process this message on SQS...??
Thanks a lot
I think you forgot to run the queue daemon.
Try to run php artisan queue:listen in the project folder.
I'm implementing a command that will process uploaded files.
The files can contain up to 300MB of data, so the job needs to be queued and I also expect that it takes a while to complete.
My problem is, when I run php artisan queue:listen it gets the job from the queue, starts processing it normally but after around 20 seconds, it freezes. The job doesn't launch any exception and neither continues so its not removed from the queue.
I'm using the database driver. Am is missing something here?
php artisan queue:listen does not output the errors for the user. Run php artisan queue:work and it will output the errors. This command will only run one process in the queue. So you need to make sure that the next process is the one you want to debug.
Maybe it does not freezes, but it seems like it froze when you see nothing happening in command line interface after you run php artisan queue:work or php artisan queue:listen command.
As in my case,
// Execute Laravel queues by queue names on coomand line interface->
I was using running command
php artisan queue:work
which was not running my queued jobs in jobs table.
Then i relaized, it was only working for jobs with queue column value = 'default'
and i had given names like sendemail, inboxemail etc.
So when i changed this other value to 'default' in queue column in jobs table,
this job ran instantly as i have opended cli and php artisan queue:work
command was active.
So if you want to run only a specific queue by queue name, run command ->
php artisan queue:listen --queue=sendemail
or
php artisan queue:listen --queue=inboxemail
For anyone making the same mistake as I did, DO NOT CREATE TABLES BASED ON THE "JOBS" TABLE!
Its not a memory leak or sth. I had another table "job_info" with a foreign key referring to the jobs table; As it turned out laravel wasn't able to remove the job from the table after it's done successfully (as it normally do). That's because it would break the relationships in the database. So it'd keep retrying until max attempts exceeded leading to an exception with no information about the actual problem.