Frequente SystemExit in Ruby bij het maken van HTTP gesprekken

stemmen
18

Ik heb een Ruby on Rails website die HTTP gesprekken maakt naar een externe Web Service.

Ongeveer één keer per dag krijg ik een SystemExit (stacktrace onder) fout e-mail waarin een oproep naar de dienst is mislukt. Als ik dan probeer exact dezelfde query op mijn site even later het werkt prima. Het is gebeurd sinds de site live gegaan en ik heb gehad geen geluk het opsporen van wat de oorzaak is.

Ruby is versie 1.8.6 en rails is versie 1.2.6.

Iemand anders dit probleem?

Dit is de fout en stacktrace.

Een SystemExit opgetreden /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: 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 noemen' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread'/ usr / local / lib / ruby ​​/ 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 request' /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 beginnen' /usr/local/lib/ruby/1.8/net/http.rb:379:in GET_RESPONSE'

De vraag is gesteld op 02/08/2008 om 18:26
bron van user
In andere talen...                            


4 antwoorden

stemmen
8

Met behulp van fcgi met Ruby is bekend als zeer buggy te zijn.

Vrijwel iedereen is verhuisd naar Mongrel om deze reden, en ik raad je hetzelfde te doen.

antwoordde op 02/08/2008 om 18:50
bron van user

stemmen
8

Het is alweer een tijdje geleden dat ik gebruikt fcgi maar ik denk dat een fcgi proces zou een SystemExit gooien als de draad te lang nam. Dit zou de webservice reageert niet of zelfs een langzame DNS-query. Sommige google resultaten laten een soortgelijke fout met Python en fcgi zo ontroerend om bastaard zou een goed idee zijn. Dit bericht is mijn referentie ik vroeger opstelling bastaard en ik verwijs nog steeds terug naar het.

antwoordde op 03/08/2008 om 06:22
bron van user

stemmen
1

Ik zou ook een kijkje nemen op Passenger . Het is een stuk makkelijker om te gaan dan de traditionele oplossing van Apache / nginx + Mongrel.

antwoordde op 11/08/2008 om 17:36
bron van user

stemmen
5

Ik gebruikt om deze hele tijd op Apache1 / FastCGI krijgen. Ik denk dat het wordt veroorzaakt door FastCGI opknoping voordat Ruby wordt gedaan.

Overschakelen naar bastaard is een goede eerste stap, maar er is meer te doen. Het is een slecht idee om het ruimen van web services op live-pagina's, met name uit Rails. Rails is niet thread-safe. Het aantal gelijktijdige verbindingen u kunnen ondersteunen gelijk aan het aantal van bastaarden (of Passenger processen) in uw cluster.

Als u een bastaard en iemand toegang heeft tot een pagina met een webservice die 10 seconden duurt om een ​​time-out belt, zullen elk verzoek om uw website een time-out in die tijd. Het merendeel van de load balancers gewoon doorlopen uw bastaards blindelings, dus als je twee bastaarden, elk ander verzoek zal een time-out.

Alles wat onvoorspelbaar kan vertragen moet gebeuren in een wachtrij. De eerste hit van / slow / action voegt de opdracht naar de wachtrij en / langzaam / action blijft vernieuwen via de pagina wordt vernieuwd of vragen via ajax totdat de taak is voltooid, en vervolgens de resultaten uit de wachtrij krijgt. Er zijn een paar job wachtrijen voor Rails tegenwoordig, maar de oudste en waarschijnlijk meest gebruikte men BackgrounDRb .

Een ander alternatief, afhankelijk van de aard van uw app, is om de dienst te ruimen elke N minuten via cron, lokaal in de cache van de gegevens, en je hebt je live-pagina te lezen uit de cache.

antwoordde op 30/08/2008 om 05:55
bron van user

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