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! 
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance
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.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"