Hyppig SystemExit i Ruby når du gjør HTTP-oppkall

stemmer
18

Jeg har en Ruby on Rails nettside som gjør HTTP samtaler til et eksternt Web Service.

Om en gang om dagen jeg får en feilmelding epost SystemExit (stakksporing nedenfor) hvor et kall til tjenesten mislyktes. Hvis jeg da prøver nøyaktig samme søket på nettstedet mitt øyeblikk senere fungerer det fint. Det har foregått siden nettstedet gikk live, og jeg har hatt noe hell å spore opp hva som forårsaker det.

Ruby er versjon 1.8.6 og rails er versjon 1.2.6.

Alle andre som har dette problemet?

Dette er feil, og stakksporing.

En SystemExit skjedde /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/ skinne-1.2.6 / lib / fcgi_handler.rb: 116: i 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 kaller' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread'/ usr / local / lib / rubin / 1.8 / net / protocol.rb: 133: i rbuf_fill '/usr/local/lib/ruby/1.8/timeout.rb:56:in timeout' /usr/local/lib/ruby/1.8/timeout. rb: 76: i 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 / rubin / 1.8 / net / http.rb: 2006: i read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in forespørsel' /usr/local/lib/ruby/1.8/ net / http.rb: 945: i 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 starte' /usr/local/lib/ruby/1.8/net/http.rb:379:in get_response'

Publisert på 02/08/2008 klokken 17:26
kilden bruker
På andre språk...                            


4 svar

stemmer
9

Bruke fcgi med Ruby er kjent for å være veldig buggy.

Praktisk talt alle har flyttet til kjøter på grunn av dette, og jeg anbefaler deg å gjøre det samme.

Svarte 02/08/2008 kl. 17:50
kilden bruker

stemmer
8

Det har gått en stund siden jeg brukte FCGI men jeg tror en FCGI prosessen kunne kaste en SystemExit hvis tråden tok for lang tid. Dette kan være den webtjeneste som ikke svarer eller en treg DNS-spørring. Noen Google-resultatene viser en lignende feil med Python og FCGI så flytte til kjøter ville være en god idé. Dette innlegget er mitt referanse Jeg pleide å sette opp kjøter og jeg fortsatt se tilbake på det.

Svarte 03/08/2008 kl. 05:22
kilden bruker

stemmer
5

Jeg pleide å få disse hele tiden på Apache1 / FastCGI. Jeg tror det er forårsaket av FastCGI henger opp før Ruby er gjort.

Bytte til kjøter er et godt første skritt, men det er mer å gjøre. Det er en dårlig idé å innhente fra webtjenester på live-sider, spesielt fra Rails. Rails er ikke trådsikre. Antall samtidige tilkoblinger du kan støtte lik antall kjøtere (eller passasjer prosesser) i din klyngen.

Hvis du har en kjøter og noen åpner en side som kaller en web-tjeneste som tar 10 sekunder til annen ut, vil hver forespørsel til nettstedet ditt timeout i denne perioden. De fleste av belastningsfordelt bare bla gjennom de kjøtere blindt, så hvis du har to kjøtere, annenhver forespørsel vil timeout.

Alt som kan være uforutsigbart treg må skje i en jobbkøen. Det første treffet til / treg / action legger jobben til køen, og / treg / action holder på å oppdatere via sideoppdateringer eller spørsmål via ajax til jobben er ferdig, og så får du resultatene fra jobbkøen. Det er noen jobbkøer for Rails i dag, men den eldste og sannsynligvis mest brukte man er BackgroundRB .

Et annet alternativ, avhengig av innholdet i appen, er å innhente tjenesten hver N minutter via cron, cache data lokalt, og har live siden lest fra cache.

Svarte 30/08/2008 kl. 04:55
kilden bruker

stemmer
1

Jeg vil også ta en titt på passasjer . Det er mye lettere å komme i gang enn den tradisjonelle løsningen av Apache / Nginx + kjøter.

Svarte 11/08/2008 kl. 16:36
kilden bruker

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