neighborland/resque_solo

resque plugin to add unique jobs

resque_solo's Issues

Jobs aren't being queued

When Resque::Plugins::UniqueJob is included in my job class, the job doesn't get queued at all. Initially I thought this was a potential conflict with Resque Retry, but I've removed that for testing purposes and the jobs still don't get queued.

I'm using Resque in conjunction with the following plugins:

gem 'resque_solo'
gem 'resque-pool'
gem 'resque-retry'
gem 'resque-scheduler'
gem 'resque-web'
gem 'resque-scheduler-web'

My job looks like this:

class AgentCheckJob
  include Resque::Plugins::UniqueJob

  @queue = :check

  # Given an Agent id, load the Agent, call #check on it, and then save it with an updated `last_check_at` timestamp.
  def self.perform(agent_id)
    agent = Agent.find_by(id: agent_id)
    return unless agent

    begin
      return if agent.unavailable?
      agent.log "Checking: #{agent.name}"

      agent.check
      agent.last_check_at = Time.now
      agent.save!

      agent.log "Done: #{agent.name}"
    rescue => e
      agent.error "Exception during check. #{e.message}: #{e.backtrace.join("\n")}"
      raise
    end
  end
end

Gem not working through `perform_later` due to ActiveJob's ResqueAdapter overriding klass with JobWrapper?

Hey!

Suppose we have a class MyJob, inheriting from ApplicationJob:

class MyJob < ApplicationJob
  include Resque::Plugins::UniqueJob
  ...
  ...
  def perform(object_id)
    ..
  end
end

By doing:

Resque.enqueue MyJob, object_id

we bypass the middle things happening inside ActiveJob framework and we call directly Resque.enqueue, which has been overriden by this gem, so the work of scheduling unique jobs is done fine.

However, when scheduling a background job through the common perform_later

MyJob.perform_later(object_id)

then this goes through ActiveJob framework, which will be utilizing the corresponding ResqueAdapter, which in turn triggers Resque.enqueue but with klass set to JobWrapper
https://github.com/rails/rails/blob/main/activejob/lib/active_job/queue_adapters/resque_adapter.rb#L31-L34

To my understanding, this unfortunately makes then the is_unique? check done by this gem to be always failing because that JobWrapper class will not have the ::Resque::Plugins::UniqueJob included, thus not adhering to create unique jobs.

resque_solo/lib/resque_solo/queue.rb

Lines 34 to 38 in 8f64d4a

	def is_unique?(item)
	const_for(item).included_modules.include?(::Resque::Plugins::UniqueJob)
	rescue NameError
	false
	end

Do I miss something obvious?
If yes, what?
If not, are there any suggestions to overcome this?

Thanks a lot in advance!

Using resque-scheduler 4.0.0 does not create key resque:solo

Hi!

I'am using resque-solo and resque-scheduler (4.0.0) with its "cronfile"

I've noticed that the jobs are running in parallel. I expected that using resque-solo, resque-scheduler could not enqueue a job that was already running.

I was monitoring redis and I've noticed that the key resque:solo:queue... is only being deleted, I couldn't see any command to create/set this key

Am I doing something wrong?

$ redis-cli monitor | grep solo

1448909636.770702 "del" "resque:solo:queue:worker_x:job:86fd876d33242629e92bdd69d81f8626"
1448909651.239846 "del" "resque:solo:queue:worker_x:job:c0ab5f17e0801db8b2501ffa915a9c5c"
1448909667.033185 "del" "resque:solo:queue:worker_x:job:caca80022e5baf00fa450005b7dc534e"
1448909739.145888 "del" "resque:solo:queue:worker_x:job:55f4dd3bd601860526db1ac51125fa51"
1448909789.734518 "del" "resque:solo:queue:worker_x:job:958a6669df3e81f9227e990a588d2780

Update docs to show how to use lock_after_execution_period option

Very small thing, but helpful for first-time users.

PR in #8

Use before hook to check job existence instead of overriding #enqueue_to

See #6, which was merged. That works but I don't think it's the best way.

resque_solo does not play well with scheduled jobs

Hi,

I am using https://github.com/wanelo/counter-cache to schedule counting jobs that get enqueued automatically after a few actions. Unfortunately counter-cache is not smart in the sense that it doesn't detect if a job is already in the queue, hence why I started using resque_solo which works perfectly for "immediate" counting jobs, it does not work with schedule ones.

As you can see:

some of these jobs have the same signature and same timestamp. I'd argue that jobs with the same timestamp and signature should not be in the queue at the same time, correct?

Thank you

#enqueued? ... when being worked on?

Is it possible that enqueued? only returns true when a job is waiting in the queue? And then, when a worker picks it up, it returns false? It looks like you query redis, but i'm not familiar with the resque protocol.

I'm trying to find out if a job is in the queue OR is being worked on. In the process, so to speak.

Resque 1.26 support?

Would this be possible? Do we know if Resque 1.26 introduces any incompatibilities?

Compatibility with ResqueMailer

Wanted to reach out and see if anyone has used resque-solo in combination with https://github.com/zapnap/resque_mailer?

We're considering adding resque-solo into our stack - no obvious issues comes to mind, but my knowledge of resque is admittedly shallow.