SystemExit frequente in Ruby quando si effettuano chiamate HTTP

voti
18

Ho un sito web Ruby on Rails che effettua chiamate HTTP a un servizio Web esterno.

Circa una volta al giorno ricevo una mail di errore SystemExit (stacktrace sotto) in cui una chiamata al servizio è fallito. Se allora provo la stessa query miei momenti del sito in seguito funziona benissimo. E 'avvenuto in quanto il sito è andato in diretta e non ho avuto fortuna rintracciare che cosa provoca.

Ruby è la versione 1.8.6 e la versione 1.2.6 rotaie è.

Qualcun altro ha questo problema?

Questo è l'errore e stacktrace.

Uno SystemExit verificato uscita /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/ rails-1.2.6 / lib / fcgi_handler.rb: 116: in 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 chiamare' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread'/ usr / local / lib / rubino / 1.8 / net / protocol.rb: 133: in rbuf_fill '/usr/local/lib/ruby/1.8/timeout.rb:56:in timeout' /usr/local/lib/ruby/1.8/timeout. RB: 76: in 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: in read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in richiesta' /usr/local/lib/ruby/1.8/ net / http.rb: 945: in 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 iniziare' /usr/local/lib/ruby/1.8/net/http.rb:379:in GET_RESPONSE'

È pubblicato 02/08/2008 alle 18:26
fonte dall'utente
In altre lingue...                            


4 risposte

voti
8

Uso fcgi con rubino è noto per essere molto buggy.

Praticamente tutti hanno spostato a Mongrel per questo motivo, e vi consiglio di fare lo stesso.

Risposto il 02/08/2008 a 18:50
fonte dall'utente

voti
8

E 'stato un po' da quando ho usato fcgi ma penso che un processo fcgi potrebbe gettare uno SystemExit se il thread stava prendendo troppo tempo. Questo potrebbe essere il servizio web non risponde o anche una query DNS lento. Alcuni risultati di Google mostrano un errore simile con Python e fcgi così di trasferirsi a Mongrel sarebbe una buona idea. Questo post è il mio riferimento che ho usato per l'installazione meticcio e ho ancora fare riferimento ad esso.

Risposto il 03/08/2008 a 06:22
fonte dall'utente

voti
1

Vorrei anche dare un'occhiata a passeggero . E 'molto più facile andare avanti rispetto alla soluzione tradizionale di Apache / nginx + Mongrel.

Risposto il 11/08/2008 a 17:36
fonte dall'utente

voti
5

Ho usato per ottenere questi tutto il tempo su Apache1 / FastCGI. Penso che sia causato da FastCGI appesi prima di Ruby è fatto.

Il passaggio a bastardino è un buon primo passo, ma non c'è più da fare. E 'una cattiva idea quella di abbattere dai servizi web sulle pagine dal vivo, in particolare da Rails. Rotaie non è thread-safe. Il numero di connessioni simultanee è possibile sostenere è uguale al numero dei meticci (o processi passeggeri) nel cluster.

Se si dispone di un bastardo e qualcuno accede a una pagina che chiama un servizio web che impiega 10 secondi per time out, ogni richiesta per il vostro sito sarà timeout durante quel tempo. La maggior parte dei bilanciatori di carico basta scorrere le bastardi alla cieca, quindi se avete due meticci, ogni altra richiesta sarà timeout.

Tutto ciò che può essere imprevedibilmente lento deve accadere in una coda di lavoro. Il primo colpo a / lento / azione aggiunge il lavoro alla coda, e / lento / azione continua a rinfrescare tramite aggiornamenti di pagina o query tramite la tecnologia AJAX fino a quando il lavoro è finito, e quindi si ottiene i risultati dalla coda. Ci sono alcune code di lavoro per Rails al giorno d'oggi, ma la più antica e probabilmente la maggior parte ampiamente utilizzato uno è BackgroundRB .

Un'altra alternativa, a seconda della natura della vostra applicazione, è quello di abbattere il servizio ogni N minuti tramite cron, cache i dati in locale, e avere la vostra pagina in diretta letta dalla cache.

Risposto il 30/08/2008 a 05:55
fonte dall'utente

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