HTTP कॉल करते समय रुबी में वारंवार सिस्टमएक्सिट

Question

मेरे पास रेल वेबसाइट पर रूबी है जो बाहरी वेब सेवा पर HTTP कॉल करता है।

दिन में लगभग एक बार मुझे सिस्टमएक्सिट (नीचे स्टैकट्रैक) त्रुटि ईमेल मिलता है जहां सेवा के लिए कॉल विफल हो गई है। यदि मैं फिर अपनी साइट के क्षणों पर सटीक वही क्वेरी आज़माता हूं तो यह ठीक काम करता है। यह तब से हो रहा है जब साइट लाइव हो गई थी और मुझे इसका कोई कारण नहीं था कि इसका कारण क्या है।

रूबी संस्करण 1.8.6 है और रेल संस्करण 1.2.6 है।

किसी और को यह समस्या है?

यह त्रुटि और स्टैकट्रैक है।

एक SystemExit बाहर निकलने /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in हुआ ' /usr/स्थानीय/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.rbs50:in to_proc '/usr/local/lib/ruby/1.8/net/protocol.rb:133:in कॉल' /usr/local/lib/ruby/1.8/net/protocol । आरबी: 133: सिस्रेड में /usr/local/lib/ruby/1.8/net/protocol.rb:133:in rbuf_fill ' /usr/local/lib/ruby/1.8/timeout.rb:56:in टाइमआउट ' /usr/local/lib/ruby/1.8/timeout.rb:76:in टाइमआउट ' /usr/local/lib/ruby/1.8/net/protocol.rb:132:in rbuf_fill' /usr/local/lib/रूबी/1.8/नेट/प्रोटोकॉल.आरबी: 116: readuntil ' /usr/local/lib/ruby/1.8/net/protocol.rb:126:in readline' /usr/local/lib/ruby ​​/ 1.8/नेट/http.rb: 2017: read_status_line ' /usr/local/lib/ruby/1.8/net/http.rbs006:in read_new' /usr/local/lib/ruby/1.8/net/ में http.rb: 1047: अनुरोध में ' /usr/local/lib/ruby/1.8/net/http.rb:945:in request_get' /usr/local/lib/ruby/1.8/net/http.rb: 380: get_response ' /usr/local/lib/ruby/1.8/net/http.rbotic43:in' /usr/local/lib/ruby/1.8/net/http.rb:379:in get_response में '

Answer 1

रुबी के साथ fcgi का उपयोग करना बहुत छोटी है।

व्यावहारिक रूप से सभी इस कारण से Mongrel पर चले गए हैं, और मैं आपको ऐसा करने की सलाह देता हूं।

Answer 2

यह थोड़ी देर हो गया है क्योंकि मैंने एफसीजीआई का उपयोग किया था, लेकिन मुझे लगता है कि अगर थ्रेड बहुत लंबा समय ले रहा था तो एक एफसीजीआई प्रक्रिया सिस्टमएक्सिट फेंक सकती है। यह वेब सेवा प्रतिक्रिया नहीं दे सकती है या यहां तक ​​कि एक धीमी DNS क्वेरी भी हो सकती है। कुछ Google परिणाम पाइथन और एफसीजीआई के साथ एक समान त्रुटि दिखाते हैं, इसलिए मोंगल पर जाने के लिए एक अच्छा विचार होगा। This post मेरा संदर्भ है जो मैं mongrel सेटअप करने के लिए प्रयोग किया जाता था और मैं अभी भी इसे वापस संदर्भित करता हूं।

Answer 3

मैं Passenger पर भी एक नज़र डालेगा। Apache/nginx + Mongrel के पारंपरिक समाधान से जाने के लिए यह बहुत आसान है।

Answer 4

मैं इन्हें Apache1/fastcgi पर हर समय प्राप्त करता था। मुझे लगता है कि रुबी होने से पहले फास्टसीगी लटक रही है।

मोन्गेल पर स्विच करना एक अच्छा पहला कदम है, लेकिन ऐसा करने के लिए और कुछ है। लाइव पृष्ठों पर विशेष रूप से रेल से वेब सेवाओं से हटना एक बुरा विचार है। रेल थ्रेड-सुरक्षित नहीं है। समवर्ती कनेक्शन की संख्या जो आप समर्थन कर सकते हैं, आपके क्लस्टर में मोंग्रेल्स (या यात्री प्रक्रियाओं) की संख्या के बराबर होती है।

आप एक संकर जाति का है और किसी को एक पेज है कि एक वेब सेवा है कि समय के लिए बाहर करने के लिए 10 सेकंड लेता है कॉल तक पहुँचता है, तो अपनी वेबसाइट के लिए हर अनुरोध उस समय के दौरान समय-समाप्त होगा। लोड बैलेंसर्स सिर्फ अपने mongrels के माध्यम से चक्र आँख बंद करके के अधिकांश, इसलिए यदि आप दो mongrels है, हर दूसरे अनुरोध का समय समाप्त होगा।

कोई भी चीज जो अप्रत्याशित रूप से धीमी गति से की जरूरत हो सकता है एक नौकरी कतार में होने की।/धीमी गति से/कार्रवाई करने के लिए पहली हिट कतार में काम कहते हैं, और/धीमी गति से/कार्रवाई ajax के माध्यम से पृष्ठ रीफ्रेश या प्रश्नों के माध्यम से ताज़ा जब तक काम समाप्त हो गया है पर रहता है, और फिर आप नौकरी कतार से अपने परिणाम मिलता है। वहाँ रेल के लिए कुछ काम कतारों आजकल सबसे पुराने और शायद सबसे व्यापक रूप से इस्तेमाल एक BackgroundRB है रहे हैं, लेकिन।

एक अन्य विकल्प, आपके ऐप्स की प्रकृति के आधार पर, क्रॉन के माध्यम से सेवा हर एन मिनट चुनना, स्थानीय स्तर पर डाटा को कैश, और अपने लाइव पृष्ठ कैश से पढ़ा है।