-
Notifications
You must be signed in to change notification settings - Fork 75
Open
Description
I recently upgraded some gems and found that Sidekiq began complaining and crashing web processes because of use-after-fork of Redis file descriptors.
This was fixed by duplicating my sidekiq-configuring initialize code into puma.rb (in the same place where Sequel has disconnect run on its connection pool) but I can't help but feel there is some anti-feature or missing pattern here that Sidekiq or Sequel connects in my pre-fork puma process.
It's not clear to me what the right way to fix this is.
My concrete approach, for example's sake:
initializers/sidekiq.rb
# Suppress configuring Sidekiq when inside a Puma process: instead,
# Sidekiq is configured after-fork in `puma.rb`, to avoid Redis
# connection file descriptor re-use errors.
unless ARGV.any? { |a| a =~ /puma/ }
test_hash = if ENV['APP_ENV'] == 'test'
{ namespace: 'test' }
else
{}
end
redis = { url: Config.redis_url }.merge(test_hash)
Sidekiq.configure_client do |config|
config.redis = redis
end
Sidekiq.configure_server do |config|
config.redis = redis
end
endpuma.rb
on_worker_boot do
# force Sequel's thread pool to be refreshed
Sequel::DATABASES.each(&:disconnect)
# Ditto, but for Sidekiq.
test_hash = if ENV['APP_ENV'] == 'test'
{ namespace: 'test' }
else
{}
end
Sidekiq.configure_client do |config|
config.redis = { url: Config.redis_url }.merge(test_hash)
end
endMetadata
Metadata
Assignees
Labels
No labels