rindek
Setting up proper uniqueness options for Queue in Oban
Hi everyone,
I’m currently working on a project using Oban Pro 1.4.0 with Smart Engine, and I need some guidance on configuring a queue with multiple workers. Specifically, I have the following requirements:
- The queue should execute a maximum of 10 jobs per node.
- It should not execute more than one unique worker with the same arguments globally (i.e., no more than one instance of the same worker/arguments combination should run simultaneously across the entire cluster).
- If a worker with the same arguments is already executing, any new job with the same worker/arguments combination should be placed in the available or scheduled state, so it can be processed immediately after the current one finishes.
Here’s what I’ve tried so far:
Oban Queue Configuration:
my_queue: [
local_limit: 10,
global_limit: [allowed: 1, partition: [fields: [:args, :worker]]]
]
Worker Configuration:
use Oban.Worker,
queue: :my_queue,
unique: [
fields: [:args, :worker],
states: [:available, :scheduled, :retryable],
period: :infinity
]
However, when running tests, I noticed that if I enqueue the same worker with the same arguments 15 times, it starts executing 10 workers and puts 1 in the available state. I expected it to execute 1 worker and also put 1 in the available state since it’s the same worker and arguments.
In contrast, if I enqueue 15 different unique worker/arguments combinations, I would expect it to start executing 10 jobs and puts the remaining 5 in the available state.
I’m running multiple different workers for the same queue, so I can’t rely only on args or only on the worker; I need to rely on both.
Is it possible to configure Oban in this way? If so, what adjustments do I need to make?
Thanks for your help!
First Post!
sorentwo
In your worker configuration the states list doesn’t include executing, so an executing job is no longer considered unique and you’ll end up with multiples.
That’s fine, global partitioning by worker and args is possible. However, I suggest using an explicit list of keys whenever possible for predictability and performance.
[allowed: 1, partition: [:worker, args: :some_key]]
Based on your criteria it sounds like you might want to use the Chain worker rather than uniqueness.
Chain workers link jobs together to ensure they run in a strict sequential order. Downstream jobs won’t execute until the upstream job is
completed,cancelled, ordiscarded. Behaviour in the event of cancellation or discards is customizable to allow for uninterrupted processing, holding for outside intervention, or cascading cancellation.Jobs in a chain only run after the previous job completes successfully, regardless of snoozing or retries.
Chains use the same partitioning format as queues, so optimally you’ll match the options to ensure only one job in a chain runs at once. There’s more in the Optimizing Chains section of the module docs.
Most Liked
rindek
Thank you very much, I will collect all the info and try to craft the appropriate solution for my needs ![]()
Last Post!
sorentwo
That’s a concurrency issue, not uniqueness.
Limiting concurrency by args is exactly what queue partitioning in Pro accomplishes.
Trending in Questions
Other Trending Topics
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
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










