"WARNING: you don't own a lock of type ExclusiveLock" in Development #388
Comments
|
@newbenji hmm, that's unexpected for you to receive that warning: The warning is output by the database adapter. It means that the current database connection (thread) is trying to unlock an Advisory Lock that does not exist. Can you say more about where you're seeing this? |
|
i see it from the cronjobs im running
the good_job started like this
bundle exec good_job start --max-threads=10 --enable-cron --queues="*"
i know the max_threads in the config is not used in this case, but wanted
test both scenario.
and its in both async and external i get the warning
execution_mode: :external,
max_threads: 5,
poll_interval: 30,
shutdown_timeout: 25,
enable_cron: true,
cron: {somejobs}
Den ons. 29. sep. 2021 kl. 16.02 skrev bensheldon ***@***.***
…:
@newbenji <https://github.com/newbenji> hmm, that's unexpected for you to
receive that warning:
WARNING: you don't own a lock of type ExclusiveLock
The warning is output by the database adapter. It means that the current
database connection (thread) is trying to unlock an Advisory Lock that does
not exist.
Can you say more about where you're seeing this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#388 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABAH3AHJU2VRVTASTL5AWS3UEML7TANCNFSM5E7G5EXA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
--
Kind regards
|
|
Are you seeing this in your development environment, or in production? Could you try adding this to an initializer ( # Output Postgres notifications through Rails.logger instead of stderr
ActiveSupport.on_load :active_record do
ActiveRecord::ConnectionAdapters::AbstractAdapter.set_callback :checkout, :before, lambda { |conn|
raw_connection = conn.raw_connection
next unless raw_connection.respond_to? :set_notice_receiver
raw_connection.set_notice_receiver do |result|
Rails.logger.info(result.error_message)
end
}
end...and then share the logs that are produced (the initializer above will make sure that the Postgres warning shows up in the logs, rather than going to stderr). Also, I wrote out some of these hints too for some lock causing problems I've run across: #329 (comment) |
|
I see this in my development environment! It seems to happen around the times I change code and the code reloading takes place. |
|
Thank you @mchristen! I was able to reproduce it in development with code reloading. When a Rails reloads the code, the database connection that is used to take the initial advisory lock is not the same connection used to release the lock. I'm only seeing this when code reloading is enabled , not in a Production configuration (fhew!) I will put together a fix for this. Relates to #95 which has a lot of early reloading lessons. |
bensheldon
changed the title
bensheldon
changed the title
|
I have a fix for this released: https://github.com/bensheldon/good_job/releases/tag/v2.3.1 |
|
thx awsome and fast response. i must aggree i only saw the error on development |
|
I'm seeing this when running in development mode and using the external execution mode. |
|
@mikehale hmm, that's unexpected because nothing should be taking an advisory lock with external execution mode. Could you tell me where it's coming from? Something like adding a |
|
Steps to reproduce:
|
|
Also getting this warning, in combination with Was not able to reproduce it in development/test on my local machine or in production. The annoying part is, that when it happens on gitlab ci, that the runner will lock up completely, until I kill the runner, or it gets killed after 1h by the timeout It only startet to appear, after I introduced code with a lot of after_commit calls |
|
I'm also getting the It happens every 5 runs or so. GoodJob uses stock configuration, no modifications. Rails 7.1.3.2, PostgreSQL 16.2, good_job 3.27.3. 
I wonder whether we should open a new issue? |
|
If I disable parallelization I don't observe the above issue. |
|
Maybe open a new issue for better visibility if it is only related to test parallelization. Briefly, I imagine that some part of GoodJob is being set up (maybe in the initial process that manages the subprocesses?) and then it's losing its database connection. That error basically means "GoodJob expected this database connection to hold an advisory lock, but it doesn't" which probably means the initial database connection was closed and a new one was opened in its place. |
Thanks @bensheldon . I'll see if I can create some test codebase to reliably reproduce the issue and then open an issue. |
First of all great job.
Working on migration some jobs to good_job.
but i get this warning out.
WARNING: you don't own a lock of type ExclusiveLock
But i cant find documentation to support it, or im not good at finding it
The text was updated successfully, but these errors were encountered: