Laravel queues not working

后端 未结 9 1011
梦谈多话
梦谈多话 2020-12-31 01:02

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

相关标签:
9条回答
  • 2020-12-31 01:24

    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

    queue_driver=database
    

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

    php artisan queue:table
    php artisan migrate
    

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

    0 讨论(0)
  • 2020-12-31 01:25

    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:

    /**
     * Create a new job instance.
     *
     * @return void
     */
    public function __construct($errorInfo)
    {
        $this->errorInfo = $errorInfo;
    
        // Queues won't run the handlers during transactions
        // so, detect the level, and if it is not 0, rollback to force job handling
        if (\DB::transactionLevel() != 0) {
            \DB::rollBack();
        }
    }
    

    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.

    0 讨论(0)
  • 2020-12-31 01:28

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

    ProcessCourseInteractions::dispatch($courseProcessing)->onQueue('course_interactions');
    

    That queue is not executed by:

    php artisan queue:work
    

    and

    php artisan queue:listen
    

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

    php artisan queue:work --queue=course_interactions
    
    0 讨论(0)
  • 2020-12-31 01:31

    Update for Laravel 5.7:

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

    Then:

     # Creates a migration for the database table holding the jobs
    php artisan queue:table
    
     # Executes the migration
    php artisan migrate
    
     # Kicks off the process that executes jobs when they are dispatched
    php artisan queue:work
    
    0 讨论(0)
  • 2020-12-31 01:32

    I am seeing that you already have Queue table.

    Try running php artisan queue:listen --tries=3 or php artisan queue:work etc.

    Queue work is for executing only one Job per command. So if there are 20 jobs in the table you might have to run queue work 20 times. That's why you can run queue:listen command. But it eats up a lot of CPU.

    In the server, you might want to run your queue listen with max 3 tries in the background. SSH to your server in the Terminal / Command Prompt. Then CD to your project directory where the artisan file lives. Run this command:

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

    In this case jobs will automatically be processed in the background. You just have to dispatch the job. And I would recommend using failed-jobs table. If you are using background queue listner.

    Hope this helps.

    0 讨论(0)
  • 2020-12-31 01:33

    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...

    ./artisan up;

    0 讨论(0)
提交回复
热议问题