Re^2: Equivalent for delayed

Replies are listed 'Best First'.
Re^3: Equivalent for delayed_job? by vsespb (Chaplain) on May 25, 2013 at 13:39 UTC
I did not check if this particular feature exists. I just suggested that you can take a look on Gearman as it's pretty good solution for perl.. If feature does not exists, maybe you should change your workflow a bit.. Maybe CRON + Job server ? I have experience working with several project (using Ruby on Rails+delayed_job and Ruby on Rails+resque) where scheduling done in such way: Cron (or analog) task executed at particular point of time. Task is lightweight and what it do is scheduling of (a thousands) of tasks to be immediately executed by job server. For example if you sending massive weekly newsletter at 19:00 Saturday. That's just a cron task which schedule it. Actual send is made by job server If you need to expire user passwords in 30 days after it last changed - it's a task, ran each day, which fetches expired passwords and queue expiration If you need expire sessions after 1 hour, it's a task again, which is run each minute, it fetches expired sessions and queue expiration tasks for each session Or you have use-case which does not fit this? p.s. in Rails we also had to use some framework to autogenerate cron tasks at deploy time	[reply]

Replies are listed 'Best First'.

Re^3: Equivalent for delayed_job?
by vsespb (Chaplain) on May 25, 2013 at 13:39 UTC

I did not check if this particular feature exists. I just suggested that you can take a look on Gearman as it's pretty good solution for perl..

If feature does not exists, maybe you should change your workflow a bit.. Maybe CRON + Job server ?

I have experience working with several project (using Ruby on Rails+delayed_job and Ruby on Rails+resque) where scheduling done in such way:

Cron (or analog) task executed at particular point of time. Task is lightweight and what it do is scheduling of (a thousands) of tasks to be immediately executed by job server.

For example if you sending massive weekly newsletter at 19:00 Saturday. That's just a cron task which schedule it. Actual send is made by job server

If you need to expire user passwords in 30 days after it last changed - it's a task, ran each day, which fetches expired passwords and queue expiration

If you need expire sessions after 1 hour, it's a task again, which is run each minute, it fetches expired sessions and queue expiration tasks for each session

Or you have use-case which does not fit this?

p.s. in Rails we also had to use some framework to autogenerate cron tasks at deploy time

[reply]