trabajadores rieles Resque fallan con PGError: servidor ha cerrado la conexión de forma inesperada

Question

tengo sitio ejecuta la aplicación de los carriles y los trabajadores resque ejecuta en el modo de producción, en Ubuntu 9.10, rieles 2.3.4, rubí-EE 2010.01, PostgreSQL 8.4.2

Trabajadores constantemente levantaron errores: PGError: el servidor cerró la conexión inesperadamente.

Supongo que el proceso maestro resque establece conexión con db (p. Ej. Authlogic cuando usa User.acts_as_authentic), al cargar clases de aplicación de rieles, y esa conexión se daña en fork() proceso de ed (¿al salir?) , así que los próximos hijos con bifurcaciones se rompen globalmente ActiveRecord :: Base.connection

Pude reproducir un comportamiento muy similar con esta sample code imitación de fork/processing en resque worker. (AFAIK, los usuarios de libpq recomiendan volver a crear conexiones en el proceso bifurcado de todos modos, de lo contrario no es seguro)

Pero, lo curioso es que cuando uso pgbouncer o pgpool-II en lugar de conexión pgsql directa, tales errores no aparecen .

Entonces, la pregunta es ¿dónde y cómo debo excavar para descubrir por qué está roto para la conexión normal y está trabajando con pools de conexión? O una solución razonable?

Answer 1

Cuando creé Nestor, tuve el mismo tipo de problema. La solución fue restablecer la conexión en el proceso bifurcado. Ver el código correspondiente al http://github.com/francois/nestor/blob/master/lib/nestor/mappers/rails/test/unit.rb#L162

Desde mi mirada limitada al código Resque, creo que una llamada a #establish_connection debe hacerse justo por aquí: https://github.com/resque/resque/blob/master/lib/resque/worker.rb#L123

Answer 2

no se puede pasar una referencia libpq a través de un tenedor () (o a un nuevo hilo), a menos que su aplicación tenga mucho cuidado de no usarlo de manera conflictiva. (Como, un mutex alrededor de cada intento de usarlo, y nunca debes cerrarlo). Esto es lo mismo para las conexiones directas y el uso de pgbouncer. Si funcionó en pgbouncer, eso fue pura suerte al perder una condición de carrera por alguna razón, y eventualmente se romperá.

Si el programa utiliza bifurcan, se debe crear la conexión después de el tenedor.

Answer 3

Después de hacer un poco de investigación/ensayo y error. Para cualquiera que se encuentre con el mismo problema. Para aclarar qué gc mencionado.

Resque.after_fork = Proc.new { ActiveRecord::Base.establish_connection } 

Por encima de código debe insertarse en: /lib/tasks/resque.rake

Por ejemplo:

require 'resque/tasks' 

task "resque:setup" => :environment do 
    ENV['QUEUE'] = '*' 

    Resque.after_fork do |job| 
    ActiveRecord::Base.establish_connection 
    end 

end 

desc "Alias for resque:work (To run workers on Heroku)" 
task "jobs:work" => "resque:work" 

Espero que esto ayude a alguien, tanto como lo hizo por mí.

Answer 4

Cambiar la configuración de Apache y añadir

PassengerSpawnMethod conservative 

Answer 5

yo tuvimos este problema con todas mis clases Mailer y yo necesitaba para llamar ActiveRecord::Base.verify_active_connections! dentro de los métodos anuncio publicitario con el fin de garantizar una conexión fue hecha.