Do not enqueue already running/already enqueued job

[ssaunier]

Hi @lantins,

That would be great to merge the commit saroka/resque-lock-timeout@e1d459225444bd19195d81c1c07f5fb92b71721f in your gem and bump a 0.4.0.

You gem provide locking to ensure that no more than one job defined by identifier is running at the same time. The patch by @saroka goes beyond by enforcing that no more than one job is running or enqueud.

It's handy when you enqueue jobs due to user request (example: a user asks for a PDF report which takes time to compute). In that case if the user ask it again, we don't want to enqueue the job again.

What do you think?

Thanks!

[lantins]

@ssaunier

Thank you for your detailed brief, the commit looks straight forward. I'll test and get back to you.

On 7 Nov 2012, at 15:01, Sébastien Saunier notifications@github.com wrote:

Hi @lantis,

That would be great to merge the commit saroka/resque-lock-timeout@e1d4592 in your gem and bump a 0.4.0.

You gem provide locking to ensure that no more than one job defined by identifier is running at the same time. The patch by @saroka goes beyond by enforcing that no more than one job is running or enqueud.

It's handy when you enqueue jobs due to user request (example: a user asks for a PDF report which takes time to compute). In that case if the user ask it again, we don't want to enqueue the job again.

What do you think?

Thanks!

— Reply to this email directly or view it on GitHub.

[lantins]

I dislike moving acquisition of a lock (the call to acquire_lock!) from around_perform hook to before_enqueue:

• Users #lock_failed hook methods will no longer be executed by the worker/job.
• It feels wrong... Exclusivity of the job/args in the queue should be dealt with separately from locking.
• Already possibly by using the resque-loner plugin.

I wont merge this commit as is. Though you've pointed out making the job exclusive in the queue goes very nicely with locking... I've lovingly accept a pull request along these lines

• Enable/disable functionality using job option/setting (see how @lock_timeout = 30 or overloading #lock_timeout works).
• Mechanism/logic to ensure queue exclusivity does not directly reuse #aquire_lock! (like referenced commit). Ideally using a before_enqueue hook.
• Extra points for updating documentation.

[ssaunier]

Hi @lantins,

Thanks for the feedback. I already had a look to resque-loner but it prevents to enqueue more than once the same job, but does not take into account running jobs. Say you have 4 works, and you click 6 times on "Export" => the 4 workers will run the export job, one will get enqueud and the sixth one discarded as one is already enqueued. Not really what we wanted :)

I'll work on a PR following the 3 points you described.

Thanks.