Skip to content

More flexibility in initializers to avoid duplication in puma.rb #301

Description

@fdr

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
end

puma.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
end

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions