ruby-on-rails - rubyonrails - ruby web
Frecuencia de salida del sistema en Ruby al realizar llamadas HTTP (4)
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:in read_status_line ''/ usr / local / lib / ruby / 1.8 / net / http.rb: 2006: en 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:i n get_response ''/usr/local/lib/ruby/1.8/net/http.rb:543:in start'' /usr/local/lib/ruby/1.8/net/http.rb:379:in get_response ''
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.
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.
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 eliminar el servicio cada N minutos a través de cron, almacenar en caché los datos localmente y hacer que su página en vivo se lea desde el caché.
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.