-
Couldn't load subscription status.
- Fork 0
Raise error when advisory lock cannot be acquired #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
398e520 to
5787303
Compare
f213213 to
d9749ba
Compare
81a4b14 to
618ef8a
Compare
466b321 to
cad9d07
Compare
83e3782 to
a21a037
Compare
a21a037 to
0e6fbf5
Compare
d9249be to
ef54cd3
Compare
ef54cd3 to
ae7b44f
Compare
|
ahh I forgot to squash my commits 😢 |
Gitlab Issue: https://gitlab.com/jklabsinc/OpsLevel/-/issues/13122
I found traces where jobs fail with a lock timeout after 50s when inserting into
entity_node_hierarchyso that means our jobs do fail if the actual insert is taking long.But there are traces (example) where the job sits for minutes just doing
SELECT GET_LOCKuntil it gets shutdown by sidekiq. TheSELECT GET_LOCKcomes from the closure_tree gem and the gem always callswith_advisory_lockwithout any options which means that it waits indefinitely for the lock.So this MR uses
with_advisory_lock!so that it raises an error if we can't get the lock instead of just waiting indefinitely so that the jobs will end up in the dead set if there's a lot of contention. https://github.com/ClosureTree/with_advisory_lock/blob/master/lib/with_advisory_lock/concern.rb#L16