resquebundle / resque

ResqueBundle for Symfony 4+
MIT License
50 stars 29 forks source link

Delayed jobs are not executed #62

Closed jellesmets closed 3 years ago

jellesmets commented 3 years ago

Version: 4.1.2 Symfony: 4.4.18 PHP: 7.4.3

I followed the documentation to schedule delayed jobs, thus via: $resque->enqueueIn($seconds, $job); in PHP after starting the scheduled worker app/console resque:scheduledworker-start

I can see on the resque homepage that the job is added to the scheduled queue. But the job is not transferred to the default queue at the expected timestamp, and is thus never executed.

Other jobs are normally executed via the standard workers. Can you reproduce/acknowledge this issue? Or might it be related to the dependent library resque/php-resque?

PhilETaylor commented 3 years ago

Are you sure your scheduled worker is starting?

We run tens of thousands of scheduled jobs every day using this exact same method

Which release https://github.com/resquebundle/resque/releases are you using?

jellesmets commented 3 years ago

Thanks for your reply!

I am using release 4.1.2 as mentioned on top of my previous message. After running app/console resque:scheduledworker-start, I got a message like Worker started bb4b90dc2f67:691 in the console so I assume the scheduled worker has started. However I can't see the worker on the /resque/workers page. I only see the standard workers here. Is this normal? On the resque main page, I see the job in the scheduled queue. The job is supposed to be executed on the default queue when the timestamp is reached, but nothing happens. Screenshot from 2021-09-01 17-47-45 Screenshot from 2021-09-01 17-47-29

PhilETaylor commented 3 years ago

try putting the scheduler in the foreground and see if there are any errors

app/console resque:scheduledworker-start -f -vvv

I just remembered that I use a dockerised old version of the scheduler and not the current version, so it could be that the current version is broken maybe... let me know what you see when you foreground it

jellesmets commented 3 years ago

I got a PHP error when putting in the foreground:

Starting worker /usr/bin/php7.4 /var/www/symfony/vendor/resquebundle/resque/Command/../bin/resque-scheduler
PHP Warning:  require_once(/var/www/symfony/../vendor/resque/php-resque/lib/Resque.php): failed to open stream: No such file or directory in /var/www/symfony/vendor/resquebundle/resque/bin/resque-scheduler on line 30
PHP Fatal error:  require_once(): Failed opening required '/var/www/symfony/../vendor/resque/php-resque/lib/Resque.php' (include_path='.:/usr/share/php') in /var/www/symfony/vendor/resquebundle/resque/bin/resque-scheduler on line 30

It looks like some file is missing

PhilETaylor commented 3 years ago

ah ok - I'll take a look at that later today.

PhilETaylor commented 3 years ago

Please try adding a vendor_dir to your config like this,

resque:
    vendor_dir: /var/www/symfony/vendor/
    prefix: my-resque-prefix                 # optional prefix to separate Resque data per site/app
    redis:
        host: redis                      # the redis host
        port: 6379                           # the redis port
        database: 1                          # the redis database
jellesmets commented 3 years ago

Thanks, it indeed works now and scheduled jobs are executed. But shouldn't this %kernel.project_dir%/vendor be the default value for vendor_dir? Why this only gives problems for scheduled workers, but not for standard workers?

PhilETaylor commented 3 years ago

The confusion comes from moving from kernel.root_dir to kernel.project_dir

It seems some people point their kernel.project_dir at public_html and some people point it at the root of the files (i.e above public_html so that kernel.project_dir/vendor would be right.

jellesmets commented 3 years ago

Ok, I will use this solution for the moment. Wouldn't it be possible to detect the folder structure automatically at some point? I don't see this vendor_dir option in other libraries

PhilETaylor commented 3 years ago

This bundle is very mature and has many users - we use it 24/7 with over 500 workers at mySites.guru - there is no reason not to use it

I inherited the code :) the code was far from perfect and I have just butchered it to keep it upgraded and running. Its overdue for some more love for sure, but keeping backward compatibility has always come first. PRs are always welcome if you have time and skill for that.