2012-03-26 11 views
10

Estoy intentando depurar un escenario en el que el proceso demorado_trabaja bajo ciertas circunstancias debido a un error Mysql2::Error: MySQL server has gone away.El servidor MySQL se ha salido del error en la tarea demoda_trabajo

Mi configuración es un poco compleja, pero traté de reducirla a lo básico. El método run en la clase ClustalwFlowTask se maneja como un trabajo en segundo plano. Básicamente ejecuta un comando clustalw2 (un programa que realiza múltiples alineaciones de secuencia para ADN y proteínas)

Los detalles del comando y cualquier error que ocurra durante su ejecución se deben registrar en la tabla flow_tasks y no atrapados por el método demoyed_job (ver las declaraciones update_attribute).

require 'open3' 
class ClustalwFlowTask < FlowTask 

    def run 
    # setup code ------ 

    # fasta is a file object 
    cmd = "clustalw2 -INFILE=#{fasta.path}" 

    Rails.logger.info "[INFO #{Time.now}] #{self} running #{cmd}" 
    #update_attribute(:command, cmd) 

    raw_stdin, raw_stdout, raw_stderr = Open3.popen3(cmd) 

    Rails.logger.info "*********** RAW STDERR: #{raw_stderr} ************" 

    stdin, stdout, stderr = [raw_stdin, raw_stdout, raw_stderr].map do |io| 
     s = io.read.strip rescue nil 
     io.close 
     s 
    end 

    Rails.logger.info "*************** #{stderr} *******************" 
    unless stderr.blank? 
     Rails.logger.info "============ THERE IS AN ERROR ============" 
     #update_attribute(:error, stderr) 
     return false 
    end 

    # more code here ----- 
end 

El extraño comportamiento comienza cuando un usuario no tiene instalado el clustalw2 binario, es decir, si la variable stderr en el método no está en blanco. Tenga en cuenta que descomentó todas las declaraciones update_attribute del método #run durante la depuración, por lo que no hay aparente implicación de MySQL. (Una de mis primeras intuiciones fue que el mensaje stderr es demasiado grande o contiene algo que hace que el servidor MySQL a cerrar, pero eso no parece ser el caso)

El registro delayed_job contiene lo siguiente:

2012-03-26T09:19:25-0700: [Worker(delayed_job host:JadeDragon.local pid:8998)] ClustalwFlowTask failed with ActiveRecord::StatementInvalid: Mysql2::Error: closed MySQL connection: DELETE FROM `delayed_jobs` WHERE `delayed_jobs`.`id` = 107 - 0 failed attempts 

Lo que parece estar sucediendo aquí es que el trabajo retrasado intentó eliminar una tarea exitosa de la base de datos, pero no pudo hacerlo debido a que se cortó la conexión de mysql. Esto ocurre después de la instrucción return false en el código ClustalwFlowTask#run, ya que es cuando, de acuerdo con el trabajo retrasado, la tarea finaliza correctamente.

El registro desarrollo cuenta esto:

================ THERE IS AN ERROR ================ 
    (0.5ms) BEGIN 
Mysql2::Error: MySQL server has gone away: BEGIN 
    SQL (0.2ms) DELETE FROM `delayed_jobs` WHERE `delayed_jobs`.`id` = 110 
Mysql2::Error: closed MySQL connection: DELETE FROM `delayed_jobs` WHERE `delayed_jobs`.`id` = 110 
    (0.1ms) ROLLBACK 
Mysql2::Error: closed MySQL connection: ROLLBACK 
    (0.1ms) BEGIN 
Mysql2::Error: closed MySQL connection: BEGIN 
    (0.1ms) ROLLBACK 
Mysql2::Error: closed MySQL connection: ROLLBACK 
closed MySQL connection 

Me estoy quedando sin ideas sobre cómo depurar este, por lo que cualquier ayuda sería muy apreciada.

+0

es MySQL sigue funcionando después de estos eventos? ¿El problema es reproducible o esporádico? ¿Has revisado los registros de mysql en el servidor? ¿Hay suficiente memoria en el servidor? También verifique las respuestas y el enlace en esta pregunta relacionada con SO: http://stackoverflow.com/questions/6807012/mysql2-error-mysql-server-has-gone-away –

+0

Sí, el servidor mysql aún se está ejecutando. El evento siempre es reproducible bajo las mismas circunstancias que describí. Los registros de mysql no muestran ningún error. He visto la lista de posibles causas del error "el servidor se ha ido", pero nada parece ser aplicable aquí. –

+0

@AndreaSingh, ¿Encontró una solución a este problema? Estoy enfrentando el problema exacto. Intenté volver a conectar: ​​cierto, pero tampoco funcionó. –

Respuesta

9

Trate de añadir a su reconnect: true database.yml

+0

Estaba mirando esto por bastante tiempo. Esto me solucionó. Rieles 3.2.7 –

Cuestiones relacionadas