SystemExit freqüente em Ruby para fazer chamadas HTTP

votos
18

Eu tenho um site Ruby on Rails que faz chamadas HTTP para um serviço da Web externo.

Sobre uma vez por dia eu recebo um e-mail de erro SystemExit (stacktrace abaixo), onde uma chamada para o serviço falhou. Se eu tente a mesma consulta exata em meus momentos site mais tarde ele funciona bem. Ele tem acontecido desde que o site foi ao vivo e eu não teve sorte rastrear o que ele faz.

Ruby é a versão 1.8.6 e trilhos é a versão 1.2.6.

Alguém mais tem esse problema?

Este é o erro e stacktrace.

Um SystemExit ocorreu saída /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in' /usr/local/lib/ruby/gems/1.8/gems/ trilhos-1.2.6 / lib / fcgi_handler.rb: 116: em 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 chamar' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread'/ usr / local / lib / ruby ​​/ 1.8 / net / protocol.rb: 133: em rbuf_fill '/usr/local/lib/ruby/1.8/timeout.rb:56:in timeout' /usr/local/lib/ruby/1.8/timeout. RB: 76: em 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: em read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in pedido /usr/local/lib/ruby/1.8/ net / http.rb: 945: em 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 começar' /usr/local/lib/ruby/1.8/net/http.rb:379:in GET RESPONSE'

Publicado 02/08/2008 em 18:26
fonte usuário
Em outras línguas...                            


4 respostas

votos
8

Já faz um tempo desde que eu usei FCGI mas acho que um processo FCGI poderia jogar um SystemExit se o segmento estava demorando demais. Este poderia ser o serviço web não responder ou até mesmo uma consulta DNS lento. Alguns resultados do Google mostram um erro semelhante com Python e FCGI tão comovente para mongrel seria uma boa ideia. Este post é a minha referência eu costumava mestiço configuração e eu ainda referir a ele.

Respondeu 03/08/2008 em 06:22
fonte usuário

votos
8

Usando fcgi com Ruby é conhecido por ser muito buggy.

Praticamente todo mundo se mudou para Mongrel por esta razão, e eu recomendo que você faça o mesmo.

Respondeu 02/08/2008 em 18:50
fonte usuário

votos
5

I utilizado para obter estes todo o tempo em Apache1 / fastcgi. Eu acho que é causada por fastcgi pendurados antes Ruby está feito.

Mudando para o vira-lata é um bom primeiro passo, mas há muito mais a fazer. É uma má idéia para abater de serviços web em páginas ao vivo, particularmente de Rails. Rails não é thread-safe. O número de conexões simultâneas que você pode apoiar iguala o número de mestiços (ou processos de passageiros) em seu cluster.

Se você tem um vira-lata e alguém acessa uma página que chama um serviço web que leva 10 segundos para o tempo limite, todos os pedidos para o seu site será tempo limite durante esse tempo. A maioria dos balanceadores de carga apenas percorrer seus mestiços cegamente, por isso, se você tem dois mestiços, todos os outros solicitação será tempo limite.

Qualquer coisa que pode ser imprevisível lento precisa acontecer em uma fila de trabalho. O primeiro hit para / lento / ação adiciona a tarefa para a fila, e / lento / ação continua refrescante via atualizações de página ou consultas via ajax até que o trabalho está terminado, e depois de receber os resultados da fila de trabalho. Há algumas filas de trabalho para Rails hoje em dia, mas o mais antigo e provavelmente o mais amplamente utilizado é BackgroundRB .

Outra alternativa, dependendo da natureza do seu aplicativo, é para abater o serviço a cada N minutos via cron, o cache de dados localmente, e ter sua página ao vivo lido a partir do cache.

Respondeu 30/08/2008 em 05:55
fonte usuário

votos
1

Também gostaria de dar uma olhada de Passageiros . É muito mais fácil para ir do que a solução tradicional de Apache / nginx + Mongrel.

Respondeu 11/08/2008 em 17:36
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more