Częste SystemExit w Ruby przy wykonywaniu połączeń HTTP

głosy
18

Mam Ruby on Rails WWW sprawia, że ​​połączenia HTTP do zewnętrznego serwisu WWW.

Raz dziennie dostaję SystemExit (StackTrace poniżej) e-mail o błędzie, gdzie nie powiodło się wezwanie do służby. Gdybym wtedy spróbować dokładnie to samo zapytanie na mojej stronie chwil później to działa dobrze. To dzieje się od witryny poszedł na żywo i miałem nie szczęścia tropienia, co go wywołuje.

Ruby jest w wersji 1.8.6 i szyn jest wersja 1.2.6.

Ktoś inny ma ten problem?

Jest to błąd i StackTrace.

SystemExit nastąpiło /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in wyjścia”/usr/local/lib/ruby/gems/1.8/gems/ szyny-1.2.6 / lib / fcgi_handler.rb: 116: w 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 nazywamy' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread”/ usr / local / lib / rubin / 1,8 / netto / protocol.rb: 133: w rbuf_fill '/usr/local/lib/ruby/1.8/timeout.rb:56:in oczekiwania' /usr/local/lib/ruby/1.8/timeout. RB: 76: wyciszony '/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: w read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in żądanie' /usr/local/lib/ruby/1.8/ net / http.rb: 945: w 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”

Utwórz 02/08/2008 o 18:26
źródło użytkownik
W innych językach...                            


4 odpowiedzi

głosy
8

Minęło trochę czasu, odkąd wykorzystywane fcgi ale myślę, że to proces fcgi mógłby rzucić SystemExit jeśli wątek został trwa zbyt długo. To może być serwis internetowy nie odpowiadać lub nawet powolny kwerendy DNS. Niektóre wyniki Google pokazują podobny błąd z Python i fcgi więc przeniósł się do kundla byłoby dobrym pomysłem. Ten post jest mój odniesienia Kiedyś konfiguracji kundla i nadal odwołują się do niego.

Odpowiedział 03/08/2008 o 06:22
źródło użytkownik

głosy
8

Korzystanie fcgi z Ruby jest znany jako bardzo buggy.

Praktycznie każdy został przeniesiony do Mongrela z tego powodu, a ja polecam zrobić to samo.

Odpowiedział 02/08/2008 o 18:50
źródło użytkownik

głosy
5

Kiedyś, aby dostać te cały czas na Apache1 / FastCGI. Myślę, że jest to spowodowane przez FastCGI wiszące przed Ruby jest wykonywana.

Przełączanie na kundla to dobry pierwszy krok, ale jest wiele do zrobienia. To zły pomysł, aby zerwać z usług internetowych na żywo stron, szczególnie z Rails. Szyny nie jest bezpieczny wątku. Liczba jednoczesnych połączeń można wspierać równa liczbie procesów kundli (lub pasażera) w klastrze.

Jeśli masz jeden kundel i ktoś otwiera stronę, która wywołuje usługę internetową, która trwa 10 sekund do czasu na zewnątrz, każdy wniosek na swojej stronie będzie limit czasu w tym czasie. Większość równoważenia obciążenia tylko cykl poprzez swoich kundli ślepo, więc jeśli masz dwa kundle, co drugi wniosek zostanie limit czasu.

Wszystko, co może być nieprzewidywalny sposób powolny musi się zdarzyć w kolejce. Pierwszym przebojem do / SLOW / akcji dodaje zadanie do kolejki i / wolno / działanie utrzymuje się na odświeżenie poprzez odświeżeniu strony lub zapytań za pośrednictwem ajax aż zadanie zostanie zakończone, a następnie dostać swoje wyniki z kolejki zadań. Istnieje kilka kolejek pracy dla Rails w dzisiejszych czasach, ale najstarszy i chyba najbardziej powszechnie stosowane z nich jest BackgroundRB .

Inną alternatywą, w zależności od rodzaju aplikacji, to usługa dokonania uboju co n minut poprzez cron, buforować dane lokalnie i mieć swoją stronę na żywo odczytywane z pamięci podręcznej.

Odpowiedział 30/08/2008 o 05:55
źródło użytkownik

głosy
1

Chciałbym również spojrzeć na Pasażera . Jest to o wiele łatwiejsze, aby zacząć zabawę niż tradycyjne rozwiązania Apache / nginx + Mongrela.

Odpowiedział 11/08/2008 o 17:36
źródło użytkownik

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