Aquí podría ser tu PUBLICIDAD


Frecuencia de salida del sistema en Ruby al realizar llamadas HTTP

votos
18

Tengo un sitio web de Ruby on Rails que realiza llamadas HTTP a un servicio web externo.

Aproximadamente una vez al día obtengo un mensaje de error de SystemExit (stacktrace a continuación) donde falló una llamada al servicio. Si luego trato exactamente la misma consulta en mi sitio momentos más tarde, funciona bien. Ha estado sucediendo desde que el sitio se lanzó y no he tenido suerte para rastrear qué lo causa.

Ruby es la versión 1.8.6 y Rails es la versión 1.2.6.

¿Alguien más tiene este problema?

Este es el error y stacktrace.

Se produjo una salida del sistema /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in exit '/usr/local/lib/ruby/gems/1.8/gems/ rails-1.2.6 / lib / fcgi_handler.rb: 116: en exit_now_handler '/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/inflector.rb:250:in to_proc '/usr/local/lib/ruby/1.8/net/protocol.rb:133:in llamada' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread '/ usr / local / lib / ruby ​​/ 1.8 / net / protocol.rb: 133: en rbuf_fill '/usr/local/lib/ruby/1.8/timeout.rb:56:in timeout' /usr/local/lib/ruby/1.8/timeout. rb: 76: en timeout '/usr/local/lib/ruby/1.8/net/protocol.rb:132:in rbuf_fill' /usr/local/lib/ruby/1.8/net/protocol.rb:116:in readuntil '/usr/local/lib/ruby/1.8/net/protocol.rb:126:in readline' /usr/local/lib/ruby/1.8/net/http.rb:2017:en read_status_line '/usr/local/lib/ruby/1.8/net/http.rb:2006:in read_new' /usr/local/lib/ruby/1.8/net/http.rb:1047:in request '/ usr / local / lib / ruby ​​/ 1.8 / net / http.rb: 945: en request_get '/usr/local/lib/ruby/1.8/net/http.rb:380:in get_response' / usr / local / lib / ruby ​​/ 1.8 / net / http.rb: 543: en el inicio '/usr/local/lib/ruby/1.8/net/http.rb:379:in get_response'

Publicado el 02/08/2008 a las 18:26
fuente por usuario Darren Greaves
En otros idiomas...        العربية       

4 respuestas

votos
8

Ha pasado un tiempo desde que utilicé FCGI, pero creo que un proceso FCGI podría lanzar un SystemExit si el hilo tardaba demasiado. Este podría ser el servicio web que no responde o incluso una consulta DNS lenta. Algunos resultados de google muestran un error similar con Python y FCGI por lo que mudarse a mestizo sería una buena idea. Esta publicación es mi referencia que solía configurar mestizo y todavía me refiero a ella.

Respondida el 03/08/2008 a las 06:22
fuente por usuario Eric Davis


Aquí podría ser tu PUBLICIDAD


votos
8

Se sabe que usar fcgi con Ruby es muy complicado.

Prácticamente todo el mundo se ha mudado a Mongrel por este motivo, y te recomiendo que hagas lo mismo.

Respondida el 02/08/2008 a las 06:50
fuente por usuario Michiel de Mare

votos
5

Solía ​​obtener estos todo el tiempo en Apache1 / fastcgi. Creo que es causado por fastcgi colgando antes de que Ruby termine.

Cambiar a mestizo es un buen primer paso, pero aún queda mucho por hacer. Es una mala idea eliminar de los servicios web en las páginas en vivo, especialmente de Rails. Rails no es seguro para subprocesos. La cantidad de conexiones simultáneas que puede admitir es igual a la cantidad de mongrels (o procesos de pasajeros) en su clúster.

Si tiene un mestizo y alguien accede a una página que llama a un servicio web que demora 10 segundos, todas las solicitudes a su sitio web expirarán durante ese tiempo. La mayoría de los equilibradores de carga simplemente recorren a ciegas a tus perros a ciegas, por lo que si tienes dos mestizos, cada otra solicitud expirará.

Cualquier cosa que pueda ser impredeciblemente lenta debe suceder en una cola de trabajos. El primer golpe a / slow / action agrega el trabajo a la cola, y / slow / action se actualiza a través de actualizaciones de página o consultas a través de ajax hasta que el trabajo finaliza, y luego obtiene los resultados de la cola de trabajos. Actualmente hay algunas colas de trabajos para Rails, pero la más antigua y probablemente la más utilizada es BackgroundRB .

Otra alternativa, dependiendo de la naturaleza de su aplicación, es sacrificar el servicio cada N minutos a través de cron, almacenar en caché los datos localmente y hacer que su página viva se lea desde el caché.

Respondida el 30/08/2008 a las 05:55
fuente por usuario cpm

votos
1

También echaré un vistazo a Passenger . Es mucho más fácil ponerse en marcha que la solución tradicional de Apache / nginx + Mongrel.

Respondida el 11/08/2008 a las 05:36
fuente por usuario Simon