10

I have two separate applications running on heroku and pointing to same database, first one responsible for user interfaceand second one for admin interface, I am using sidekiq with redis for background job processing, I have added one worker and I am able to share 'redis-server' by setting environment variable pointing to same Redis providing Addon, Now i wish to share worker too, because adding the extra worker will cost double.

Please suggest, whether this is even possible or not?

Sachin Singh
  • 7,107
  • 6
  • 40
  • 80

3 Answers3

15

If both apps are using the same Redis URL and same namespace, you can spin up one worker with that same Redis config and it will be shared by both.

Note that your Sidekiq process will boot one app or the other. The code for your Workers must be in that app. The other app won't be able to reference the code but can push jobs using:

Sidekiq::Client.push('class' => 'SomeWorker', 'args' => [1,2,3])

Note that 'class' is a String so SomeWorker can actually be defined in the other app.

Mike Perham
  • 21,300
  • 6
  • 59
  • 61
  • yes, both apps are pointing to same redis URL, and both apps are adding jobs to queue, if i don't add worker on any one app then that is unable to add jobs to redis server for processing. – Sachin Singh Sep 25 '14 at 05:48
  • @SachinSingh if this is not an answer to your question then I don't understand what your question is. – Old Pro Sep 27 '14 at 19:35
  • How would you test that a job has been pushed to the client? – Daniel Pietzsch Dec 17 '14 at 09:55
  • is this solution still applicable? I am using sidekiq 5.2.2 and I get error like this irb(main):014:0> Sidekiq::Client.push('class' => 'SomeWorker', 'args' => [1,2,3]) Traceback (most recent call last): 2: from (irb):14 1: from (irb):14:in `rescue in irb_binding' NoMethodError (undefined method `get_sidekiq_options' for "SomeWorker":String) – Shanky Munjal Apr 26 '22 at 11:31
  • Yes, this answer is still best practice. If you have an error, please open an issue or ask a new question. – Mike Perham Apr 26 '22 at 16:15
0

How about using 3 different heroku apps?

  1. User Interface App (ui repository)
    • web: bundle exec rails server
  2. Admin Interface App (admin repository)
    • web: bundle exec rails server
  3. Worker (admin repository)

Even if 2 and 3 use the same code base, you can have 2 different heroku apps. One that starts the admin, one that actually starts sidekiq. Would that solve your problem?

Bruno Buccolo
  • 1,111
  • 9
  • 20
0

Mike's answer is still a safe bet, though having to include all relevant sidekiq options inline everywhere you enqueue this class is a bit gross.

Here's a blog post that goes into more detail, and offers a second approach:

http://coderascal.com/ruby/using-sidekiq-across-different-applications/

Basically the alternative is to have a "proxy" class on the enqueueing application that controls the sidekiq behavior (queue, retries, etc.). Then there would be a matching class name on the receiving/de-queueing application.

The author of the blog post overrides some standard Sidekiq logic to redirect from the proxy class to the non-proxy class on the receiving side. Overriding the gem's behavior is a bit risky, and it enforces an extra convention on your class naming. But you may be able to get away with not doing that part.

Nick Davies
  • 1,011
  • 8
  • 7