Häufige SystemExit in Ruby, wenn das HTTP-Aufrufe

Question

Ich habe eine Ruby on Rails-Website, die HTTP-Aufrufe an einen externen Web-Service.

Etwa einmal am Tag bekomme ich eine SystemExit (stacktrace unten) Fehler-E-Mail, wo ein Aufruf an den Dienst versagt hat.Wenn ich dann versuche die genau die gleiche Abfrage auf meiner Website Augenblicke später funktioniert es einwandfrei.Es ist schon passiert, da die Website live gegangen und ich habe kein Glück aufspüren, was es bewirkt.

Ruby version 1.8.6 rails-version ist 1.2.6.

Sonst noch jemand dieses problem?

Dies ist der Fehler, und stacktrace.

Ein SystemExit aufgetreten /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 call' /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:in 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'

Answer 1

Mit fcgi mit Rubin bekannt ist, werden sehr buggy.

Praktisch jeder hat verschoben Mongrel aus diesem Grund, und ich empfehle Ihnen, das gleiche zu tun.

Answer 2

Es ist schon eine Weile her, dass ich verwendet, FCGI, aber ich denke, ein FCGI-Prozess werfen konnte einen SystemExit, wenn der thread war zu lange dauert.Dies könnte der web-Dienst nicht mehr reagiert oder sogar eine langsame DNS-Abfrage.Einige google-Ergebnisse zeigen einen ähnlichen Fehler mit Python und FCGI so bewegt, mongrel wäre eine gute Idee sein. Dieser Beitrag ist meine Referenz, die ich verwendet, um zu setup-Mischling und ich immer noch wieder auf.

Answer 3

Früher habe ich diese die ganze Zeit auf Apache1/fastcgi.Ich denke, es ist verursacht durch fastcgi Aufhängen, bevor Ruby ist fertig.

Wechseln zu mongrel ist ein guter Erster Schritt, aber es gibt mehr zu tun.Ist es eine schlechte Idee zu Keulen von web-services auf live-Seiten, insbesondere von Schienen.Schienen ist nicht thread-sicher.Die Anzahl der gleichzeitigen verbindungen, die Sie unterstützen kann, entspricht der Anzahl von Mischlingen (oder Passagier-Prozesse) in Ihrem cluster.

Wenn Sie eine Promenadenmischung, und jemand greift auf eine Seite, die einen Webdienst aufruft, der dauert 10 Sekunden, um die Zeit, jeden Wunsch zu Ihrer website Zeitüberschreitung, während dieser Zeit.Die meisten der load Balancer nur Zyklus durch Ihre Köter blind, also, wenn Sie zwei Köter, jede andere Anforderung timeout.

Alles, was unvorhersehbar langsam passieren muss, um in einem job in der Warteschlange.Der erste Treffer auf /langsam/Aktion wird der job in die Warteschlange, und /slow/action hält auf erfrischende über die Seite aktualisiert oder Anfragen über ajax bis der job abgeschlossen ist, und dann bekommen Sie Ihre Ergebnisse aus der job-Warteschlange.Es gibt ein paar job-Warteschlangen für Schienen heute, aber die älteste und wohl am meisten verbreitet ist BackgroundRB.

Eine weitere alternative, abhängig von der Art der app, ist zu Keulen der service alle N Minuten via cron, cache Daten lokal und haben Ihre live-Seite aus dem cache gelesen.

Answer 4

Ich würde auch einen Blick auf PKW.Es ist viel leichter zu gehen, als die traditionelle Lösung des Apache/nginx + Mongrel.