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.
Related
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 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
I'm running a laravel app on Azure. Things are moving in the right direction, composer install didn't use to work at all. Now however, the "php artisan optimize" command times out:
However, running "php artisan optimize" separately is no problem at all:
What could be the cause of this?
Edit:
Deleting the symfony-folder does not help, it is not present when I run the "Composer install"-command:
Increasing the timeout-limit does not help either, I increased it in both azure and in the composer.json file:
This still gives me a timeout, after installing the symfony-components again:
...
As I deployed a new clean Laravel 5 application to Azure Web apps and tried to reproduce your issue, however, it worked fine on my side either I run the command php artisan optimize or composer install or composer update.
I installed the composer at the Site extensions at the KUDU console site of the application on Azure Web apps, the url should be like: https://<your_site_name>.scm.azurewebsites.net/SiteExtensions/#gallery
There are several solutions of other developers who occur the same issue with you, you can try these solutions:
try to increase the max_execution_time or set the value to 0, refer to https://azure.microsoft.com/en-us/documentation/articles/web-sites-php-configure/#how-to-change-the-built-in-php-configurations to change the PHP build-in configurations on Azure Web Apps. And you can change the process-timeout in Composer.json file :
"config" : {
"process-timeout": 0
}
deleted the entire Symfony folder and try again. As the comments at PHP Artisan Optimize - Timed out? #1050, it seems the symfony dependencies raise the issue.
#Rkey,
According to my experience, I think the issue is more related to the symphony version/configuration. I suggest you can remove/edit the symphony configuration from the composer.lock file (NOTE: please backup this file if you cannot success, you also can recovery your environment). And then you can run this "composer install".
After installed component, You can see an alert window which shows that
your session is timeout, please refresh your browser.
You can see this information because the server is in initialization process.
Any concerns, please feel free to let me know.
I'm also having this problem. Will upgrading the plan help?
According to this upgrading to S3 helps... I haven't tried it though... Let me know if it really works.
#Rkey & #cabs, per my understanding on this question, I wanna point out that Composer is not fully supported on Azure. The issue is that it’s using Taskkill command which is blocked on Azure. We are aware of this and please feel free to submit an idea or suggestion based on the experience with Azure at https://feedback.azure.com/forums/34192--general-feedback.
I have been stuck in this problem as well for a week.
Have tried all solutions on forum but no success.
This morning finally solved after reinstall XAMPP. It was problem on my previous PHP version 5.6.19. While using new XAMPP with PHP version 5.6.28, it worked fine.
I have a PHP app running on heroku (cedar stack). I'm at the point where I need to start passing jobs off to workers.
I've looked a both RabbitMQ and gearman. It seems like the best / simplest solution for my app would to use gearman.
So I'm guessing the gearman server would run on the main webapp dyno and then the gearman workerapi would run on separate heroku workers, along with the php code that should do the work.
How can I go about doing this with Heroku?
Thanks
Queuing is best done with an addon https://addons.heroku.com/#queues. The link ( devcenter.heroku.com/articles/background-jobs-queueing ) in the comment to your question by ficuscr should provide you with some insight as to how exactly to implement your workers.