Unlock queue on dequeue

[humancopy]

Unlocks a queue when dequeue is called, using the before dequeue hook (see: humancopy/resque@5042244).

It also stores the lock in a hash so it's easier to remove all locks if needed.

There are still deadlocks happening when using Resque.remove_queue to remove the whole queue. Still thinking on this one... :)

[defunkt]

Why?

[humancopy]

Couldn't run tests with this gem. Was getting this error message:

~/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/test/unit/assertions.rb:5:in module:Test': Unit is not a module (TypeError)`

The tests run without it and the rake file is testing if the command exists, so i figured it should be optional. :)

[defunkt]

Fair enough!

[humancopy]

Still trying to think of a way to remove the locks when removing the whole queue. Since remove_queue is called on Resque and not on the queue's class itself, and it's not possible to get the class from the queue name - i'm stuck on this... :)

One way I thought to resolve this is to force the queue name on the lock. Something like this:

def lock_id
  "#{@queue}:#{lock}"
end

def lock(*args)
  args.to_s
end

Then in the code of Resque::Plugins::Lock call lock_id instead of lock, so lock can still be used to customize the lock's name.

And then still need to be able to add a hook on remove_queue of Resque class.

I can try to implement this, let me know if you're interested :)

[humancopy]

Hey ...

I've reverted back the hash change (for speed), so it now uses normal Redis keys again.

I also added another class method for defining if the lock should be lifted or kept for running jobs. It was required in one project where it was important for jobs with same args to get queued even if the same job is running. I called it lock_running?, though I think the name is not descriptive enough of it's use, but couldn't think of something better. Any ideas?

Enjoy ;)

[dylanahsmith]

Why is namespaced_lock defined with the same behaviour lock used to have, but only use lock in namespaced_lock