I use supervisord to configure and run laravel queues as a background job on the linux machines. One of my customer can only use windows machine due to their company policy.
I want to run laravel queue as a background job on windows. I've came up with this solution below but I am not so sure if it is good way to do it.
forever -c php artisan queue:listen --tries=3
Anyone has tried it in production if yes how was experience with that or anyone has better solution with this situtation?
Any help would be highly appreciated.
Related
I know you can stop all workers in Laravel using queue:restart. But I'm looking for a way to stop all workers working on a specific queue. Something like this:
php artisan queue:restart --queue=my_queue
As far as I read the documentation,
php artisan queue:clear redis --queue=emails
is only available for The SQS, Redis, and database queue drivers.
But this command is clearing, not stopping.
So I might be misunderstanding something here and I'm not 100% sure if it's a Horizon problem, or a Supervisor problem, but was looking to see if anyone had experienced this before.
Essentially (and I don't think this is just limited to Horizon processes) it appears that Supervisor just doesn't attempt to restart any processes (at least, not all of the time).
I've currently got it running on 8 different servers (some our own dedicated hosting, others Digital Ocean droplets, and an AWS EC2 instance).
There are a variety of Laravel, PHP and Supervisor versions (from Laravel 5.7 and Supervisor 4.0.4 to Laravel 7.2.1 and Supervisor 3.4.0 - which seems to be latest version available in the CentOS repository and might need updating anyway)
This is an example config file that I'm using, which is essentially the same as the one provided in the Laravel docs.
process_name=%(program_name)s
command=/usr/bin/php /var/www/<domain>/artisan horizon
autostart=true
autorestart=true
user=centos
redirect_stderr=true
stdout_logfile=/var/www/<domain>/log/horizon.log
stopwaitsecs=3600
I don't believe the issue to be memory related as usage is usually pretty low at the time and I'm not seeing errors in that regard.
The log file is usually just the same thing over and over again:
Horizon started successfully.
Which I assume is from whenever it has actually managed to restart, or when I've done it manually.
I've read another question on here that suggested that the user had the wrong command in the config, but I've verified this and used full paths to make sure it's correct.
Hopefully, someone here has more experience with this than I do?
I'm trying to use Laravel Queues for sending emails using the database driver, I have already configured it, run the migration for the "jobs" table and when I run this:
Mail::to($user->email)->queue(new CompraRealizadaAdmin(Cart::content(), $monto_descuento, $envio, $user_array, $direccion, $compra));
A record is added on the "jobs" table, but, how do I run the queue on the database table?, I understand that for triggering it at the moment it is added, I will need to run the command php artisan queue:listen, or if I need to run all the ones that are still on queue, I will use php artisan queue:work.
But how do I run the command without the need to open terminal and keep it open until it has finished...?
I had the idea of creating a schedule and run it every minute and just execute the code: Artisan::call('queue:work'); but that does not work.
Any ideas?
Depending on your needs, preferences and your target OS you can use
supervisord (cross platform)
upstart / systemd (linux)
launchd (OS X)
or alike services to manage your queue worker processes.
In fact Laravel documentation explains in great detail how to install and configure supervisord for this.
It depends on which OS you are working on for Ubuntu or linux you can use supervisor and hup.
butt be careful you have to run hup every time you reboot your machine.
thats how you can run this command. hup php artisan queue:work.
Hope this helps
I have deployed my app on shared host "Hostgator", I've ssh successfull access, however I can't install supervisor to manage queue processing, the command sudo apt-get install supervisor always return errors, so I have contacted support and I was told that I can't make sudo commands with sharedhost "cloud" plan and I have to move to VPS or dedicated which I can't move to at this time.
My question is : is there any alternative can I use to manage the queue processing without supervisor or another way to go around this ? anybody wen through this and found a solution ?
I was thinking to make a cron job with command php artisan queue:work every morning maybe but is this a good practice ?
Thanks in advance any help is appreciated.
For anyone there who is going through something similar, I managed that by cron jobs that run every hour but you have to migrate failed jobs table to make sure that failed jobs are handled and don't stop the queue processing, even though this is not ideal but it somehow works. The ideal solution is considering VPS hosting or mixing Laravel Forge with DigitalOcean for example as mentioned in laravel docs.
Cheers.
I noticed that the queued jobs do not appear in new relic as transactions of any kind.
After digging for a bit I found that if I run my artisan queue workers "straight" they do appear just fine but if I run them as daemons (That's what I have set for my artisan queue:work commands in supervisord config) they do not.
Why does it work that way? Is there anything that can be done about it?
I wanna keep them with --daemon set to avoid framework bootstrapping for every single job. However being able to see what's going on in new relic is important as well.
Scheduled commands and regular http requests seem to be tracked just fine.
I'm running Laravel 5.2 on several forge servers with both php 5.6 and 7.0.
Thank you
New Relic added out-of-the-box instrumentation support for Laravel Queues as an experimental feature in version 6.6.0. Check if your agent version is at least 6.6.0 and then add this property to your newrelic.ini:
newrelic.feature_flag=laravel_queue
For more info, check out the release notes:
https://docs.newrelic.com/docs/release-notes/agent-release-notes/php-release-notes/php-agent-660169