Long-running queued background processes

If you need to be able to restart because of electricity shutdown, you must have your jobs-to-do in database. In that case a simple solution is to use Oban.

Oban will let you control how much workers you will have in your queue.

Infortunately if the server shutdowns during execution of an Oban job, on restart Oban will believe that the job is still “executing” and will not restart it (except if you use Oban Pro). But if you have a single instance of your application running, that is easy: On start, check if there is any job with the “executing” state in database and set it to “available”. And only then start the Oban queue.

Not sure how Ash could help there though.

@lud is right - I feel like Oban is the way to go here. We have ash_oban to help ease the integration but it’s not a hard requirement.

Reactor is only really useful if you have a multi-step process that you want to orchestrate. You can run a reactor inside your Oban job if you decide to go that way.

Also look at ash_state_machine as it may be relevant.

Thank you for your response.

Thanks, will look into Oban.

Yeah, that is what I was doing in the Go version. I had a table with jobs and their state (waiting, in-progress, done).

Sure. That was a problem we faced in the original implementation as well. And we solved exactly that way: upon server start, reset all jobs that were marked in-progress.

Just reading up on Oban. Definitely is something I need to look into. Will also look at ash_oban to see what it does.

Oh, okay. I’ll be honest I just skimmed through the documentation quite quickly. Even if it is not the right thing for this particular project, it looks interesting and deserves some attention at some point.

In the original implementation, we used a field in the database table to store the current state of each job and then I transitioned between states. So yes, ash_state_machine does look interesting from that point of view, especially as I can define rules for which state transitions are allowed (if I read that right). Again, seems really useful, not just for this project but for many of the types of project I typically work on.

You don’t need Pro to rescue stuck jobs (orphans), that’s available with the standard Lifeline plugin. The difference with Pro is it isn’t as smart about restarts.

Side note—every persistent queue may either drop executing jobs silently (like Sidekiq), or you’ll have orphans that need to be dealt with. It’s a good thing!

Ah!

I hesitated to ping you here for this but I checked it before and a google search for “oban lifeline” returns this page for v2.9.1 stating that This plugin is available through Oban.Pro.

But in your link for 2.16.3 the mention is gone Thanks for making it available!

That’s good to know. I live in a part of the world where unfortunately the price of pro might be out of reach for some of our clients. So I’ll have to live with what I get and try to work around it myself. I have a habit of personally donating to open source projects that I rely upon so will need to investigate the possibility of donating to the open source effort at least. For now, that is probably the best I can do.

the price of pro might be out of reach for some of our clients

Don’t worry, Oban free is already an excellent product

Be careful with this approach if you plan on ever adding distribution or any kind of rolling deploys to the application. How can it tell that it’s starting clean or it’s starting while another instance is already running?

Good point, but is not a problem in this particular case. But I’ll keep that in mind.