A few years ago a built a system in Go that I’m trying to rebuild as a part of learning more about Ash and Phoenix. This involved users being able to generate various reports relating to water bodies in West Africa. We got the data by talking to a remote web service. This was usually very slow and it could take quite a while to get a repsonse back. In addition, we were only supposed to allow a limited number of report requests to run at a time (a value that they admins could change). Once we got a reponse back we would pull out the relevant information from the JSON and send it to a report server which would generate a report and give us a link which we could pass on to the user. Do to issues with electricity and stuff, the pending jobs would have to be able to restart if something were to happen and the service needed to be restarted.
I’m interested in how to conceptually tackle this using Ash. I’m sure I could pretty much follow the procedure I did in Go, but it feels like Ash provides functionality that might be of use here. I’m looking at the state machine and/or possibly the reactor? I have really dug into these yet, but it “smells” like one or both of them might be useful in some way.
I’d like to know if there is some Ash-esque way of dealing with those requirements and what that would involve. The Go solution ended up working well enough, but the code was a bit of a nightmare both to maintain and to build upon.
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.
@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.
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!
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.
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?
Thanks for making it available!
