tovarchristian21
Simple Job Queue - limiting my app to executing a single job at the time
lately I’ve had some trouble with a very simple task, which is limiting my app to executing a single job at the time. On the previous days I managed to implement something like that using Oban, everything went smoothly and great on my local machine, however when I deployed to Heroku, I did no expect that the application would behave so weird due to the 3 Dynos 2X I currently use. After failing with that implementation after being deployed, I need to replace it with something that does that, and nothing else, I will really miss all the features Oban has, but I just need to execute a single Job at once, despite having multiple requests, those will have to be enqueued until the job is done in order to proceed with a new job. Do you guys something that can help with my current situation? BTW, I’ll have to stick to Heroku for now, I wish I could deploy on Gigalixir and keep the Oban implementation, I’m sure it could work on a regular instance, but for now I do not have other options of deployment.
Marked As Solved
sorentwo
Using the example that @outlog posted you’ll end up with two dyno types: web and worker. They will run the exact same code but the goal is to have only the worker run your jobs.
This is a variant on splitting-queues where you either run a queue or you don’t. Here’s how you’d define it in your application.ex:
defmodule MyApp.Application do
@moduledoc false
use Application
alias MyApp.Repo
alias MyAppWeb.Endpoint
def start(_type, _args) do
children = [
Repo,
Endpoint,
{Oban, oban_config()}
]
Supervisor.start_link(children, strategy: :one_for_one, name: MyApp.Supervisor)
end
defp oban_config do
opts = Application.get_env(:my_app, Oban)
if worker_enabled?() do
opts
|> Keyword.put(:crontab, false)
|> Keyword.put(:queues, false)
else
opts
end
end
defp worker_enabled? do
System.get_env("OBAN_WORKER") == "true"
end
end
Also Liked
mbuhot
I think you should be able to nominate one of the dynos to run the Oban worker that consumes from the queue, while the other dynos don’t run the worker process.
lucaong
tovarchristian21
That was exactly what I needed. Thank you very much. Only replaced the :queues to false it the worker_enabled?/1 returned false… but aside from that, I never thought each node ran the same supervision code, it was something very transparento to my eyes. Thanks to everyone that helped me out! 
mbuhot
I thought Heroku had built in support for independently scaled worker processes without needing a whole new app? https://devcenter.heroku.com/articles/background-jobs-queueing#process-model
sorentwo
Using Oban.insert does require a running Oban instance. You can insert jobs freely with Repo.insert, but you won’t get telemetry, unique support, dynamic repos, or automatic prefixing.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"