Should I use rails5 ActiveJob default async adapter for small background job in production?

Question

Rails app which handle and activation of a license using an external service, the external service sometime delays the handling of rails request to over 30s, which will then return an error to front end (I'm running heroku, so max is 30s).

I tried using ActiveJobs and the default rails async adapter (Rails 5), and I can see that is working in Heroku out of the box. I keep reading that I should be using another web process and for example redis, but if the background job should just be performed straight after the request is done and if is just hitting another API outside which may be slower, is it so bad to use the default async?

I can see that this is handle in an in-process thread but I don't see a reason for such small job to be having another web process.

Saxena

Answer 1

I use the async adapter in production for sending emails. This is a very small job. An email could take up to 3 seconds to send.

The doc said it's a poor fit for production because it will drop pending jobs on restart. If I remember correctly, Heroku restarts dynos once a day.

If your job is pending during the restart, the job will be lost. For my case, a pending email during the restart is pretty slim. So far so good.

But if you have jobs taking 30 seconds, I'll use Resque or DelayedJob.

Apostolic

Answer 2

If for small background job in production, which does not require 100% persistence in case of failure/server restart, whose duration is relatively short and thus separate process would be an overkill, I'd recommend using Sucker Punch.

Sucker Punch gem is designed to handle exactly such case. It prepares execution thread pool for each Job you create, using the concurrent-ruby gem, which is (probably) the most robust concurrency library in Ruby. It also hooks on_exit to finish all the pending tasks, so I guess you can expect this gem to be more reliable than the AsyncJob.

One thing to note is that although Sucker Punch is supported on Active Job, the adapter is not well written. Or, at least, when you use Sucker Punch adapter, it's behavior would be just like that of async adapter. So, I'd recommend using bare Sucker Punch if you wanted something just a little more useful/robust than AsyncJob.

Destinydestitute

From the Sucker Punch Readme: "What is the difference between sucker_punch and ActiveJob::QueueAdapters::AsyncAdapter? Not much at this point. SuckerPunch existed before ActiveJob, but ultimately uses similar code under the covers. I'd recommend using AsyncAdapter if you're using Rails." – Radack