Gyakori SystemExit Ruby ha így HTTP hívást

szavazat
18

Van egy Ruby on Rails weboldal, ami HTTP hívásokat egy külső webes szolgáltatás.

Körülbelül naponta egyszer kapok egy SystemExit (stacktrace alább) hiba az e-mail, ha a hívás a szolgáltatás nem sikerült. Ha majd próbálja pontosan ugyanazt a lekérdezést az oldalamon pillanattal később már jól működik. Ez történt, mert az oldal élesben, és már nem volt szerencséje nyomon követni, mi okozza.

Ruby verzió 1.8.6 és sínek verzió 1.2.6.

Bárki más is ez a probléma?

Ez a hiba és stacktrace.

A SystemExit történt /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/ sínek-1.2.6 / lib / fcgi_handler.rb: 116: a 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 hívás' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread”/ usr / local / lib / rubin / 1.8 / net / protocol.rb: 133: a 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 / rubin / 1.8 / net / http.rb: 2006: a read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in kérelem' /usr/local/lib/ruby/1.8/ net / http.rb: 945: a 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 start' /usr/local/lib/ruby/1.8/net/http.rb:379:in get_response”

A kérdést 02/08/2008 18:26
a forrás felhasználó
Más nyelveken...                            


4 válasz

szavazat
8

Használata fcgi Ruby ismert, hogy nagyon bugos.

Gyakorlatilag mindenki költözött korcs emiatt, és azt javasoljuk, hogy tegye ugyanezt.

Válaszolt 02/08/2008 18:50
a forrás felhasználó

szavazat
8

Már egy ideje, mióta használják FCGI de azt hiszem, egy FCGI folyamat dobni egy SystemExit ha a szál túl sokáig. Ez lehet a webes szolgáltatás nem válaszol, vagy akár egy lassú DNS lekérdezést. Néhány google eredmények azt mutatják, hasonló hibát Python és FCGI így mozgó korcs lenne jó ötlet. Ezt a bejegyzést az én hivatkozás szoktam beállítási korcs, és még mindig utalja vissza rá.

Válaszolt 03/08/2008 06:22
a forrás felhasználó

szavazat
1

Azt is megnézzük utas . Ez sokkal könnyebb az indulásra, mint a hagyományos megoldás az Apache / nginx + korcs.

Válaszolt 11/08/2008 17:36
a forrás felhasználó

szavazat
5

Szoktam, hogy ezeket minden alkalommal Apache1 / fastcgi. Azt hiszem, ez okozta fastcgi lóg ki, mielőtt Ruby történik.

Váltás korcs egy jó első lépés, de van több köze. Ez egy rossz ötlet, hogy a selejtezett webes szolgáltatások élő oldalak, különösen Rails. Sínekkel nem szálbiztosak. Az egyidejű kapcsolatok száma támogatni tudja száma megegyezik az korcsok (vagy utas folyamatok) a klaszter.

Ha van egy korcs és valaki hozzáfér egy oldalt, amely felhívja a webes szolgáltatás, amely 10 másodpercig tart, hogy időt, minden kérést a honlapon timeout ez idő alatt. A legtöbb terheléskiegyenlítők csak lépkedni a korcsok vakon, így ha két korcsok, minden kérés timeout.

Bármi, ami lehet kiszámíthatatlanul lassan kell történnie egy feladatsort. Az első találatot / lassú / akció hozzáadja a feladat, hogy a sorba, és / lassú / akció tart a frissítő keresztül oldalfrissítéseket vagy lekérdezések segítségével ajax, amíg a feladat befejeződik, és akkor kap az eredményeket a feladatsor. Van néhány feladat sorok Rails manapság, de a legrégebbi és talán legelterjedtebb az egyik BackgroundRB .

Egy másik alternatíva, jellegétől függően az alkalmazás, hogy a selejt a szolgáltatás minden N perc cron, gyorsítótár az adatokat helyben, és az élő oldalon olvasható a cache.

Válaszolt 30/08/2008 05:55
a forrás felhasználó

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