![]() This method only supports a single queue worker, however you could probably modify the idea with some flag files, add a job for each worker, and wait until they are all loaded. However, php artisan queue:work -daemon will die and need to be restarted. If running php artisan queue:listen, the listener will continue to operate throughout the process seamlessly. Finally, when the application is brought back up with php artisan up, the queue worker is killed so it can reload the application environment with fresh code after the maintenance. When this job is processed, the application is taken down into maintenance mode and the queue worker remains looping that job – however command will finish so you can proceed with maintenance. When running php artisan down:safe, it will add a job into the queue and wait. $this->info("Application maintenance mode enabled.") This can be implemented as an Artisan command: php artisan down:safe How about we have the queue worker set Maintenance Mode, and keep the queue busy until the application is back online. Our aim is to enable Maintenance Mode and be confident that the queue worker is not processing anything. I decided to find a simple solution to the problem. So we either have to wait 30-60 seconds and hope the job is finished (for queue:listen), or we have to wait even longer and hope the queue is empty (for -daemon)… and we have no way of knowing either. Also, Laravel v4.2 recently added a new command, php artisan queue:work -daemon, which removes a lot of the overheads of the listen command – and completely ignores the maintenance mode setting. The queue:listen command will honor this after it finishes processing the current job – but you don’t know when that job is finished. ![]() Laravel provides a nice command to turn the application into maintenance mode: php artisan down. By leaving the workers processing while we apply and update, we’ve opened the door for issues when a database field, or function call, no longer exist, or their behavior changes in an incompatible way. We need to kill a worker when we want to update the application code and/or database. So I reject the notion that you just need to accept that jobs can be killed randomly. While this is a nice idea in theory, if you’re working with a really complex queue job (which queue jobs are designed for!), the effort involved in making sure your job can auto-recover from a crash may be immense. When I asked in the Laravel forums how to safely kill a worker, someone responded with this: “It should always be safe to kill a job, jobs should be coded like that, always assume it will happen.”. However, we have absolutely no idea if it’s actually processing a job or not – and therefore we don’t know when it’s a good time to kill the worker. It will happily keep sitting there, processing jobs when there are any available. Let’s look at this command: php artisan queue:listen ![]() Laravel has made the queuing system really simplistic, in order to make it easy to use, however it is here where it suffers from a big flaw: you can’t safely shut down a queue worker. One of the components it provides is a full Queue Worker system to make it very easy to add jobs into a queue and process them in the background. ![]() Laravel is a fantastic PHP Framework that does most of the complex, and boring, application framework tasks for you, so you can focus on the application itself. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |