lamxw2
Hi there. I am currently working on migrating our current queue system from GenServers to Oban (Pro). I am implementing this in phases, so not all entities will be running in Oban yet, which means based on a condition, some entities use our existing queue, and the remainder get queued in Oban.
We want to prioritize the entities using our existing queue system, so the plan was to pause the relevant Oban queues when the current queue is not empty, then resume Oban queues when that queue is empty.
However, I have run into Ecto.StaleEntryError
Last message: {:notification, :signal, %{"action" => "pause", "ident" => "any", "queue" => <omitted>}}
Last message: {:notification, :signal, %{"action" => "resume", "ident" => "any", "queue" => <omitted>}}
I have tried:
- Using
Oban.check_queueand pause/resume based onqueue.pausedvalue, however that requires a db query call every time an entity is queued, which is not very efficient.StaleEntryErroroccurs - Adding a boolean field
oban_pausedto my GenServer states, this prevents a db query every time. However we have multiple GenServers that share a queue, so theoban_pausedboolean is inaccurate based on the queue. This also still has aStaleEntryErroron a specific GenServer that doesn’t share a queue, so it seems like our system is too quick and a race condition happens as well. - Wrapping
Oban.pause/resume_queuein atry catch, but this doesn’t work either.
The next solution I thought of doing was manually pausing (changing the state) Oban.Job instead of the queue itself, which I think would work out better especially for our GenServer states that share a queue, since we rate limit and partition our queues based on that. However, I don’t see a suitable state that can be used, aside from scheduled, but that would require setting a time for the Job, which isn’t suitable for our use case.
I am looking for an easy workaround, because we won’t need to resume/pause queues like this after our entire current system has been moved to Oban.
Any other suggestions are welcome!
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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
benwilson512
Would using the built in priority feature work here instead of trying to juggle priority yourself via pausing and unpausing?
lamxw2
Nope it would not, because our entities have already occupied those priorities.
For the specific part that you quoted, we are “juggling” the priority ourselves because we don’t want those entities to use Oban for the time being, since we are moving them to Oban in phases.
Basically, we have entities with our own assigned priorities from 1 to >1000, with the lower number being the highest priority. Since moving an entire system is tricky, we want to move only internal priorities 300 and above to Oban, while keeping internal priorities <300 on our current system. These 1-1000+ priorities are grouped according to Oban’s 0-9 priorities.
sorentwo
The
Ecto.StaleEntryErroryou’re getting is from a bug inDynamicQueuesthat was fixed in the rather recent Pro v1.5.0-rc.4.Note that
Oban.check_queuedoesn’t query the database. It returns information directly from the queue’s producer process.The easiest workaround is to upgrade to the latest RC (it’s stable, no known bugs at this point) and avoid the annoying
.
StaleEntryErrorbuglamxw2
Hi, you may remember me from this post Getting StaleEntryError on DynamicQueues.update
I have been on the latest Oban Pro rc version ever since then, but unfortunately am facing this error now.
sorentwo
Of course
You’re positive it’s rc.4? The issue was reproducible in tests and there were numerous logic changes, including a rescue for that specific exception.
lamxw2
Yes, I’m positive. In my
mix.lock, the version is1.5.0-rc.4. Unless themix.lockisnt an accurate indicator?sorentwo
No, that’s an accurate indicator. I’m not sure how you’re still seeing that error then. Which mechanism are you using to pause? Will you share your current code?
dimitarvp
Just to remove all variables, did you do these steps?
And then try again?
lamxw2
I had not, but I just tried and it didn’t resolve it unfortunately
lamxw2
Just pausing the queue based on the queue name. Sure. I have also included the other code I tried as commented out code
1st module
ObanQueue module
set_queueis a function that just identifies the queue name based on the variable