2

The code below doesn't work. I think I have done all things correctly, but somehow I doesn't work.

... MyJob::dispatch($job)->onQueue('processing')->delay(Carbon::now()->addSeconds(30)); ...

MyJob.php

<?php

namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\SerializesModels;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;

class MyJob implements ShouldQueue
{
    use InteractsWithQueue, Queueable, SerializesModels, Dispatchable;

    public function __construct($job)
    {
        // I described a logging code here and yes, there was change, but then...
    }

    public function handle()
    {
        // I described a logging code here, but there wasn't change
    }
}

The problem is that dispatchNow() did work, but dispatch with delay didn't work.

I also set .env correctly(I guess)

.env file ...

QUEUE_CONNECTION=database

...

config/queue.php ...

'default' => env('QUEUE_CONNECTION', 'sync'),

...

Please help me. Any advice would be nice. Thank you.

PassinateDev
  • 31
  • 1
  • 4
  • You could try specifying the connection in your dispatch, by adding a ->onConnection('database'), however this should not be neccessary, and you may need to clear your cache, or change the fallback driver to 'database' aswell in your queue.php . Also, when dispatching synchronously, use the dispatchSync method, as the dispatchNow method is depracated – Oskar Mikael Apr 25 '22 at 08:05
  • Could you please share your error log? – Kmg Kumar Apr 25 '22 at 08:10
  • Thank you for your reply, Mr.Oskar Mikael. I just did try it but there was no change either. Any alternative ways? – PassinateDev Apr 25 '22 at 08:10
  • No error logs. It just doesn't work. As I said dispatchNow method works well, but dispath with delay method just doesn't work with no errors. How can I get this right? – PassinateDev Apr 25 '22 at 08:13
  • Maybe this helps you: https://stackoverflow.com/a/31091730/9636400 – geertjanknapen Apr 25 '22 at 08:19
  • `QUEUE_CONNECTION` or `QUEUE_DRIVER` Which one should I prefer to use in my code? – PassinateDev Apr 25 '22 at 08:29
  • @PassinateDev QUEUE_DRIVER was changed to QUEUE_CONNECTION in Laravel 5.7, so you are correct in using QUEUE_CONNECTION – Oskar Mikael Apr 25 '22 at 08:30
  • @Mr.Oskar Mikael Thank you. Then what can I do to execute my code? I just cleared my cache(config:clear, cache:clear) and then tried again but still no result. – PassinateDev Apr 25 '22 at 08:33
  • So, does your logging output anything in the construct and/or the handle method? Could you also show exactly what you send in to your job's constructor and what you're trying to log in the handler? What is the $job variable, there may be an error there. – Oskar Mikael Apr 25 '22 at 08:35
  • You using php artisan queue:work command right ? – Kmg Kumar Apr 25 '22 at 08:36
  • @Mr.Oskar Mikael $job is actually an integer value and it is print on log file correctly, which means that __construct works correctly. It's just the handle function that's not working. (just in case of dispatch, worked correctly when I used dispatchSync) – PassinateDev Apr 25 '22 at 08:39
  • As the above comment suggested, make sure you are running a queue worker when dispatching your job. It can be done with php artisan queue:work (this will run all jobs currently in the queue), but you can also do php artisan queue:listen (this will create a listener that will run in the background and listen for new dispatches). The reason why it works with dispatchSync is because you tell the job to run synchrounously, meaning it wont wait to queue and will run instantly – Oskar Mikael Apr 25 '22 at 08:56
  • @Mr.Oskar Mikael Thank you so much. Here's one more thing. I wrote code like \Artisan::call("queue:work")(or queue:listen) but the page doesn't go further. Any advice, please? – PassinateDev Apr 25 '22 at 09:00
  • If you are calling the queue worker from a controller, your page wont be able to load further, as the queue worker will have to run on a separate thread (since your application is served locally, and can not run multiple command from within the same thread). You could solve this by adding the flag --stop-when-empty to your artisan call, but when running in application in production, you will almost always have a separate scheduler to run your queue worker – Oskar Mikael Apr 25 '22 at 09:09
  • Is it possible your app is running on a different timezone than your database? I would check and see what time the app thinks it is vs. what time the timestamps are in your database and make sure they match. Your code looks correct on the surface so hard to tell without more context. – Rob Fonseca Apr 25 '22 at 10:43
  • When I used dispatch without delay it didn't work either. I am so confused. – PassinateDev Apr 25 '22 at 11:17
  • @PassinateDev And you performed the queue:work after dispatching the job, yes? – Oskar Mikael Apr 25 '22 at 11:22

2 Answers2

0

Diagnostic steps;

  1. Open tinker and run config('queue') and check that the queue settings are as expected

  2. Without running a queue worker, dispatch your job to the queue. Open your database tools and check that the jobs table contains one new record.

  3. run the queue worker with php artisan queue:work after the delay, the job should run.

  4. Check that the job has gone from the jobs table, and that nothing is in the failed_jobs table.

Snapey
  • 3,604
  • 1
  • 21
  • 19
0

You could try clearing your cache as advised above. Additionally, also try to restart the queue

php artisan queue:restart

As for the queue:work question. Yes if you want the queue to run permanently supervisor is a good option to use. A sample config is as below.

[program:my-laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/project/artisan queue:work --queue=QUEUE_NAME--sleep=1 --tries=1
autostart=true
autorestart=true
numprocs=1
redirect_stderr=true
stdout_logfile=/path/to/log/file.log