这是indexloc提供的服务,不要输入任何密码
Skip to content

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

@fdr

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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions