Častá SystemExit v Ruby při volání HTTP

hlasů
18

Mám Ruby on Rails webových stránek, který umožňuje volání HTTP na externí webové služby.

Asi jednou za den, kdy jsem se chybová email SystemExit (StackTrace níže), kde výzva ke službě se nezdařilo. Kdybych zkuste přesně stejný dotaz na mých okamžiků místě později to funguje dobře. To se děje, protože byl web a já jsem neměl štěstí pátrání po tom, co ji způsobuje.

Ruby je verze 1.8.6 a zábradlí je ve verzi 1.2.6.

Někdo jiný má tento problém?

To je chyba a StackTrace.

SystemExit došlo /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/ Koleje-1.2.6 / lib / fcgi_handler.rb: 116: v 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 nazýváme' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread‘/ usr / local / lib / ruby ​​/ 1,8 / net / protocol.rb: 133: v rbuf_fill /usr/local/lib/ruby/1.8/timeout.rb:56:in prodlevě /usr/local/lib/ruby/1.8/timeout. rb: 76: v časovém limitu '/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: v read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in žádost' /usr/local/lib/ruby/1.8/ net / http.rb: 945: v 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‘

Položena 02/08/2008 v 18:26
zdroj uživatelem
V jiných jazycích...                            


4 odpovědí

hlasů
8

Je to už nějaký čas, protože jsem použil FCGI, ale myslím, že proces FCGI mohl hodit SystemExit v případě, že nit trvalo příliš dlouho. To by mohlo být webová služba nereaguje ani pomalý dotaz DNS. Některé mapu výsledky ukazují podobnou chybu s Python a FCGI tak se stěhuje do kříženec by to byl dobrý nápad. Tento příspěvek je můj odkaz dřív nastavení psisko a pořád se vrátit zpět k němu.

Odpovězeno 03/08/2008 v 06:22
zdroj uživatelem

hlasů
8

Používání fcgi Ruby je známo, že je velmi buggy.

Prakticky všichni se přestěhovala do kříženec z tohoto důvodu, a já doporučuji vám udělat to samé.

Odpovězeno 02/08/2008 v 18:50
zdroj uživatelem

hlasů
5

Použil jsem se dostat tyto celou dobu na Apache1 / FastCGI. Myslím, že je to způsobeno tím, FastCGI zavěšení před udělal Ruby.

Přepnutí na psisko je dobrý první krok, ale je tu víc dělat. Je to špatný nápad, aby jatečné z webových služeb na živých stránkách, a to zejména z Rails. Rails není bezpečné podprocesu. Počet souběžných připojení můžete podpořit rovná počtu kříženců (nebo cestujících procesů) v clusteru.

Pokud máte jeden kříženec a někdo přistupuje k stránku, která volá webové služby, která trvá 10 sekund časový limit, bude každý požadavek na své webové stránky časový limit během této doby. Většina rozložení zátěže jen procházet vaše kříženců naslepo, takže pokud máte dva kříženci, každý druhý požadavek bude časový limit.

Cokoliv, co může být nepředvídatelně pomalu se musí stát ve frontě úloh. První hit do / pomalé / akce přidá úlohu do fronty, a / pomalé / action neustále osvěžující přes stránka se obnoví nebo dotazů přes Ajax, dokud není práce dokončena, a pak se dostat své výsledky z fronty úloh. Existuje několik pracovních fronty na kolejích v dnešní době, ale nejstarší a pravděpodobně nejpoužívanější z nich je BackgroundRB .

Jinou alternativou, v závislosti na povaze vaší aplikace, je jatečných Tato služba každých n minut přes cron, mezipaměti data lokálně, a nechat si živě stránky čtení z cache.

Odpovězeno 30/08/2008 v 05:55
zdroj uživatelem

hlasů
1

Také bych se podívat na cestujícího . Je to mnohem jednodušší jít než tradiční řešení Apache / Nginx + kříženec.

Odpovězeno 11/08/2008 v 17:36
zdroj uživatelem

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