Faraday: ओपन और रीड टाइमआउट के लिए टाइमआउट एरर को अलग करें

हाय @coberlin मेरा मानना ​​​​है कि यह एक अच्छा जोड़ा हो सकता है, मैं सिर्फ पीछे की संगतता के बारे में डरता हूं।
हालांकि, इसका एक संभावित समाधान यह हो सकता है कि OpenTimeoutError और ResponseTimeoutError को TimeoutError से इनहेरिट किया जाए, ताकि मौजूदा rescue s अपेक्षानुसार काम करता रहे।
यह निश्चित रूप से कुछ परीक्षण के लायक है 😃

इस सुविधा के लिए रैक_एडाप्टर गलत स्थान हो सकता है। मुझे लगता है कि रैक एप्लिकेशन ओपन और रीड टाइमआउट के बीच जरूरी अंतर नहीं करते हैं। शायद यह सुविधा HTTPClient एडेप्टर या अन्य एडेप्टर में काम करेगी? एडेप्टर/httpclient.rb से:

    @app.call env
  rescue ::HTTPClient::TimeoutError, Errno::ETIMEDOUT
    raise Faraday::Error::TimeoutError, $!
  rescue ::HTTPClient::BadResponseError => err
    if err.message.include?('status 407')
      raise Faraday::Error::ConnectionFailed, %{407 "Proxy Authentication Required "}
    else
      raise Faraday::Error::ClientError, $!
    end
  rescue Errno::ECONNREFUSED, IOError, SocketError
    raise Faraday::Error::ConnectionFailed, $!
  rescue => err
    if defined?(OpenSSL) && OpenSSL::SSL::SSLError === err
      raise Faraday::SSLError, err
    else
      raise
    end

::HTTPClient::TimeoutError में 3 उपवर्ग हैं ConnectTimeoutError,ReceiveTimeoutError, SendTimeoutError, उदाहरण के लिए देखें http://www.rubydoc.info/gems/httpclient/2.1.5.2/HTTPClient/TimeoutError

फैराडे में फैराडे :: त्रुटि :: कनेक्शन पहले से ही विफल है। क्या यह ConnectTimeoutError के लिए उपयुक्त है? फैराडे :: त्रुटि :: टाइमआउट एरर को फैराडे :: त्रुटि :: रिसीवटाइमआउट एरर और फैराडे :: त्रुटि :: सेंडटाइमआउट एरर में उपवर्गित किया जा सकता है।

फैराडे में फैराडे :: त्रुटि :: कनेक्शन पहले से ही विफल है। क्या यह ConnectTimeoutError के लिए उपयुक्त है?

यह समझ में आता है, लेकिन यह पीछे की ओर संगत नहीं होगा। हम ध्यान में रखना है कि लोगों को पहले से ही पकड़ने रहे हैं Faraday::Error::TimeoutError का उपयोग करने जा इसलिए अपने आवेदन में ConnectionFailed होगा ब्रेक उन मामलों।
इसके बजाय, हम जो करना चाहते हैं, वह Faraday::Error::TimeoutError लिए 2 उपवर्गों को परिभाषित कर रहा है, जिनके नाम यथासंभव सामान्य होने चाहिए:

• फैराडे :: त्रुटि :: ओपनटाइमआउट त्रुटि
• फैराडे :: त्रुटि :: रीडटाइमआउट त्रुटि

अगला कदम प्रत्येक एडेप्टर में जाना है और तदनुसार एडेप्टर अपवादों को मैप करना है। जैसे HTTP क्लाइंट के लिए:

• HTTPClient::ConnectTimeoutError ==> फैराडे :: त्रुटि :: OpenTimeoutError
• HTTPClient::ReceiveTimeoutError ==> फैराडे :: त्रुटि :: ReadTimeoutError
• HTTP क्लाइंट :: टाइमआउट एरर ==> फैराडे :: त्रुटि :: टाइमआउट एरर (यह सेंडटाइमआउट एरर भी पकड़ लेगा, जो मुझे यकीन नहीं है कि फैराडे या एक विशिष्ट सेटिंग में संबंधित मैपिंग है)

अंत में, जहां संभव हो वहां परीक्षण जोड़े जाने चाहिए :)

हे लोगों।

हमने यह चर्चा कुछ समय पहले की थी (https://github.com/lostisland/faraday/pull/324)।

मैं इसे एक और कोशिश दे रहा हूं (https://github.com/mistersourcerer/faraday/tree/718_mrsrcr_timeout-wrapping-2nd-chance), जैसे ही मुझे इस पर कुछ प्रगति होगी, मैं कोशिश करूंगा और एक नया पीआर खोलूंगा।

नमस्ते @mistersourcerer , कुहनी
मैं थोड़ा भ्रमित हूं क्योंकि मैं पीआर को बंद देखता हूं, लेकिन कोड में बदलाव, यह जानने के लिए है कि आपने अपना परिवर्तन किसी तरह अंत में विलय कर दिया है
इस मामले में आपकी मदद की सराहना की जाएगी क्योंकि मुझे लगता है कि आप अपने पिछले काम से टाइमआउट परीक्षण के साथ पहले से ही सहज हैं (भले ही हम 3 साल पहले बात कर रहे हों!)
मुझे उम्मीद है कि OpenTimeoutError और ReadTimeoutError पर मेरी व्याख्या स्पष्ट है, लेकिन अगर ऐसा नहीं है तो कृपया मुझे बताएं।
अपना समय लें और काम पूरा करने के बाद एक पुल अनुरोध खोलें

अरे @iMacTia।

अगर मुझे ठीक से याद है, तो हम उस समय की स्थिति को हल करने का प्रबंधन नहीं कर पाए थे। लेकिन मुझे यकीन नहीं है कि वास्तव में क्यों।
मुख्य समस्या एक परीक्षण लिखना था जो सभी एडेप्टर के बीच लगातार विफल रहा। इसलिए, मुझे नहीं लगता कि उस समय मेरा कोड मर्ज किया गया था।
वैसे भी, हाहा के कुछ साल बाद मेरे पास इसके लिए एक विचार है, देखते हैं कि यह कैसा चल रहा है।

अभी, _EMSynchrony_ के परीक्षण ट्रैविस पर विफल हो रहे हैं, लेकिन स्थानीय रूप से नहीं। इसका पता लगाने की कोशिश की जा रही है। मैं एक "शुरुआती" पीआर खोलने पर भी सोच रहा हूं ताकि शायद हम इस पर चर्चा कर सकें।

और आपकी व्याख्या बिल्कुल स्पष्ट है, इसके साथ जाने का सही तरीका लगता है।

इस पर शानदार काम के लिए धन्यवाद, यार।

धन्यवाद @mistersourcerer!

अपने परिवर्तन पुन: करें: मैं वास्तव में निश्चित नहीं हूं कि क्या हुआ, लेकिन मैं देख रहा हूं कि @mislav ने अंततः आपके परिवर्तनों को यहां विलय कर दिया: https://github.com/lostisland/faraday/commit/f73d13ee09814fa68b37efa7bddafa47331948c2

तो आनन्दित हों, Errno::ETIMEDOUT पहले से ही Faraday::Error::TimeoutError तहत अधिकांश (यदि सभी नहीं) एडेप्टर पर लपेटा गया है

इस @mistersourcerer पर काम करने के लिए धन्यवाद!

यहां आपकी प्रतिबद्धता को देखते हुए, मुझे आश्चर्य है कि पश्चगामी संगतता के लिए, हमें 2 नए उपवर्गों की आवश्यकता है: OpenConnectionError < ConnectionError Net::HTTP के लिए और OpenTimeoutError < TimeoutError HttpClient के लिए?

ऐसा लगता है कि इस मुद्दे को लेकर कुछ भ्रम है।
कारण यह है कि "ओपन टाइमआउट" त्रुटियों को ConnectionFailed रूप में संभालने के लिए #438 पर निर्णय लिया गया था। यकीनन यह सबसे अच्छा निर्णय है, लेकिन वास्तविकता यह है कि किसी ने उस रास्ते से नीचे जाने का फैसला किया है।
अब, यह न केवल रैक एडेप्टर बल्कि अन्य सभी एडेप्टर को भी प्रभावित करता है, और उनका व्यवहार शायद सुसंगत भी नहीं है।
मैं उन्हें v1.0 के साथ समान व्यवहार पर मानकीकृत करने की योजना बना रहा हूं और मैं इस मुद्दे को एक संदर्भ के रूप में रखूंगा।

मेरी पिछली टिप्पणी में अनुवर्ती।

मूल रूप से, हम वर्तमान में एक ओपन टाइमआउट के मामले में Faraday::ConnectionFailed त्रुटि उठा रहे हैं, जबकि हम रीड टाइमआउट के लिए Faraday::TimeoutError बढ़ाते हैं। हालांकि अलग-अलग एडेप्टर वर्तमान में अलग-अलग तरीकों से व्यवहार कर रहे हैं, यह सबसे सामान्य व्यवहार प्रतीत होता है।
यह 3 साल पहले की तरह कुछ तय किया गया था, लेकिन यहां हम पूर्व मामले के लिए Faraday::TimeoutError होने पर भी चर्चा कर रहे हैं (खुले और बंद के बीच अंतर करने के लिए उचित उप-वर्गों के साथ)।

एक तरफ मैं समझता हूं कि यह वास्तविकता के करीब होगा, लेकिन अगर मैं कार्यान्वयन के दृष्टिकोण से इस मुद्दे का विश्लेषण करता हूं, तो मुझे इस बदलाव को सही ठहराना मुश्किल लगता है।
अगर मैं किसी सेवा को कॉल करता हूं और मुझे ConnectionFailed वापस मिलता है, तो मुझे पता है कि मेरी कॉल को संसाधित नहीं किया जा सकता है। मैं शायद सर्वर तक नहीं पहुंचा, या होस्टनाम का समाधान नहीं कर सका, या कुछ और हुआ।
अगर मुझे TimeoutError वापस मिलता है, तो मेरा अनुरोध संसाधित हो सकता है, या आंशिक रूप से संसाधित हो सकता है, और हो सकता है कि मैं प्रतिक्रिया से चूक गया हो। यह एक पूरी तरह से अलग मामला है और जिस सर्वर को मैं कॉल कर रहा था, उसके साथ दोबारा जांच करने की आवश्यकता है।

ओपन टाइमआउट को TimeoutError उप-श्रेणी बनाने का अर्थ है एक अधिक जटिल डोमेन के तहत एक साधारण स्थिति (अनुरोध संसाधित नहीं) लेना, और निश्चित रूप से यह तय करने के लिए अतिरिक्त जांच की आवश्यकता है कि क्या करना है: क्या यह एक खुला टाइमआउट था या पढ़ा गया था समय समाप्त?

हमारे लिए आवश्यक है:

1. तय करें कि ओपन टाइमआउट को बबल-अप कैसे करें
2. सभी एडेप्टर को समान व्यवहार के लिए मानकीकृत करें

@coberlin @erik-escobedo @mislav @mistersourcerer उपरोक्त पर विचार करने के बाद आपके विचार सुनना चाहेंगे।

ओपन टाइमआउट त्रुटियों के लिए ConnectionFailed के साथ जाना मेरे लिए समझ में आता है और अन्य टाइमआउट त्रुटियों से ओपन टाइमआउट त्रुटियों को अलग करके मैं जो प्राप्त करने की उम्मीद कर रहा था वह प्रदान करेगा। एडेप्टर संगतता के लिए, इसका मतलब होगा, उदाहरण के लिए, कि Net::HTTP ठीक है, लेकिन HTTPClient बदल जाएगा, ConnectTimeoutErrors TimeoutError के बजाय ConnectionFailed में मैपिंग के साथ।

यह ठीक है, एक बार जब हम तय कर लेते हैं कि हम सभी एडेप्टर को समान व्यवहार के लिए मानकीकृत करेंगे (v1.0 में स्पष्ट रूप से, क्योंकि यह पिछड़ा असंगत होगा)

उपयोग-मामले को रिंग में फेंकना:

काम पर हम Nginx + Kubernetes के कारण हैंगिंग पॉड्स (या कुछ और) को रूट करने में विफल होने के कारण कुछ ओपन टाइमआउट से पीड़ित हैं। वैसे भी, नेटएचटीटीपी ओपनटाइमआउट और रीडटाइमआउट त्रुटियों को फेंकता था, और यह वास्तव में हमारे लिए डिबगिंग के लिए आसान था जो कि था।

अब हम टाइफियस पर स्विच कर चुके हैं, दुख की बात है कि हमारे पास सभी टाइमआउट एक साथ मंग गए हैं, और हमारे लिए यह बताना कठिन है कि क्या nginx + कुबेर समस्याओं पर हमारे काम में सुधार हुआ है, या यदि हम अभी सफलतापूर्वक एक तेजी से संघर्षरत लोगों के लिए अधिक अनुरोध कर रहे हैं प्रणाली। किसी भी तरह से टाइमआउट की संख्या लगभग समान है, और उन्हें अलग किए बिना हम अनुमान लगा रहे हैं।

मुझे नहीं लगता कि केवल Faraday::OpenTimeoutError जोड़ना पर्याप्त है, हमारे पास Faraday::OpenTimeoutError और Faraday::ReadTimeoutError Faraday::TimeoutError IMO से विस्तारित होना चाहिए।

@philsturgeon और अन्य प्रस्तावित समाधान के बारे में क्या, क्या इससे भी मदद मिलेगी?

ओपन टाइमआउट -> Faraday::ConnectionFailed
समयबाह्य पढ़ें -> Faraday::TimeoutError

यह सभी एडेप्टर पर व्यवहार होना चाहिए, लेकिन दुर्भाग्य से कुछ उम्मीद के मुताबिक व्यवहार नहीं कर रहे हैं (यानी टाइफियस)

मुझे ऐसा लगता है कि ये अलग चीजें हैं।

कनेक्शनफेल ऐसा लगता है जैसे "मुझे नहीं पता कि इस सर्वर से कैसे बात करें", जैसे अमान्य DNS/IP इत्यादि।

ओपनटाइमआउट है "मुझे पता है कि यह सर्वर कहां है, बस इसके लिए एक काम करने की प्रतीक्षा कर रहा है"

ओपनटाइमआउट है "मुझे पता है कि यह सर्वर कहां है, बस इसके लिए एक काम करने की प्रतीक्षा कर रहा है"

मैं इससे असहमत हूं, मैं कहूंगा:

ओपन टाइमआउट: मैं सर्वर से संपर्क करने की कोशिश कर रहा हूं, लेकिन मैं उस तक नहीं पहुंच सकता (नोट: कनेक्शन स्थापित नहीं हुआ या अभी तक "खोला गया")।
टाइमआउट पढ़ें: मैंने सर्वर के साथ एक कनेक्शन स्थापित किया है, लेकिन मैं इसके लिए कुछ करने की प्रतीक्षा कर रहा हूं (आउटपुट पढ़ना)।

एक दोषपूर्ण फ़ायरवॉल/प्रॉक्सी/लोड_बैलेंसर इस बात के सरल उदाहरण हैं कि आप एक ओपन टाइमआउट कैसे प्राप्त कर सकते हैं, लेकिन इन सभी मामलों में सर्वर से कनेक्शन अभी तक शुरू नहीं हुआ है। यह मेरे लिए सबसे महत्वपूर्ण बिट है। मेरे लिए "कनेक्शनफेल" का सीधा सा अर्थ है: मैं सर्वर से कनेक्ट नहीं हो सका। और यह इन मामलों में पूरी तरह से उपयुक्त है।

तुम अब भी लगता है कि एक विशिष्ट फैराडे :: OpenTimeoutError मौजूद होना चाहिए, तो मैं सुझाव देंगे कि से प्राप्त करना ConnectionFailed बजाय TimeoutError , लेकिन मैं और सहमत हैं कि थोड़ा भ्रमित हो सकता है यकीन है कि कैसे नहीं यह व्यवहार में मदद करेगा।
कृपया मेरा पिछला https://github.com/lostisland/faraday/issues/718#issuecomment -343957963 देखें कि यह वास्तव में त्रुटि को प्रबंधित करने में कैसे मदद कर सकता है।

क्या इस का कोई मतलब निकलता है? मैं एक ऐसा समाधान खोजना चाहूंगा जो सभी के लिए उपयुक्त हो

मैं ओपन टाइमआउट के लिए आपकी अधिक सटीक परिभाषाओं को स्वीकार करता हूं लेकिन मैं एक अलग निष्कर्ष पर आता हूं।

आप ओपन टाइमआउट को कनेक्शन विफलता के रूप में मानते हैं क्योंकि आप उस कनेक्शन की प्रतीक्षा करने के लिए जितना समय चाहते हैं, उसे कनेक्शन का हिस्सा माना जाता है। "5s में संबंध बनाने में विफल" निश्चित रूप से समझ में आता है यदि आप इसे इस तरह समझाते हैं, लेकिन ऐसा नहीं है कि बहुत से लोग सोचते हैं।

कई लोगों के लिए, ओपन टाइमआउट का मतलब है कि यह अभी तक नहीं हुआ

मुझे लगता है कि इससे कोई फर्क नहीं पड़ता, क्योंकि कनेक्शन विफलताओं और खुले टाइमआउट दोनों को पुनः प्रयास किया जाना चाहिए, यहां एक पठन टाइमआउट को बैक ऑफ करने का आधार माना जा सकता है?

मैं सहमत हूं, हम जितना चाहें पढ़ने पर बहस कर सकते हैं, कोई भी उस पर लागू हो सकता है, लेकिन मेरी बात की व्यावहारिकता वही है जो आपने भी कहा था: यदि आपको ओपन टाइमआउट मिलता है तो इसका मतलब है कि आप अनुरोध को पुनः प्रयास कर सकते हैं, यदि आपको मिलता है एक पठन टाइमआउट इसका मतलब है कि आपको बहुत सावधान रहना होगा क्योंकि आपका अनुरोध संसाधित हो सकता है (पूरी तरह या आंशिक रूप से)। संयोग से, ओपन टाइमआउट का व्यावहारिक अर्थ एक असफल कनेक्शन से मेल खाता है, इसलिए मैं इसे वहां से प्राप्त कर दूंगा।

आज लोग ConnectionFailed और TimeoutError अपवादों को पकड़ रहे हैं और इसके पीछे के तर्क शायद वही दर्शाते हैं जो हमने पहले कहा था। यदि हम नए अपवाद को ConnectionFailed उपवर्ग के रूप में पेश करते हैं तो संभावना अधिक है कि अधिकांश (यदि सभी नहीं) एप्लिकेशन को किसी भी बदलाव की आवश्यकता नहीं होगी।

मैं एक अर्थपूर्ण दृष्टिकोण से समझता हूं (और सहमत हूं) हालांकि ओपनटाइमआउट सिर्फ एक अन्य प्रकार का टाइमआउट है।

लेकिन हे, क्या होगा अगर हम इसके बजाय इसे ConnectionTimedOut हैं?

open_timeout: X संपत्ति का नाम होने के बारे में कुछ भ्रम होगा जो कहता है कि ConnectionTimedOut फेंकने तक कितना इंतजार करना है।

अच्छी बात

इसे ConnectionOpenTimeout ? यह इसे एक कनेक्शन समस्या को स्पष्ट करता है और यह स्पष्ट रखता है कि यह एक प्रारंभिक समयबाह्य है। मुझे लगता है कि यह नाम "एक्स सेकेंड में कनेक्शन बनाने में विफल" अर्थ के अनुरूप समझ में आता है, भले ही कुछ लोग अभी भी आश्चर्यचकित हों कि टाइमआउट टाइमआउट क्यों नहीं है। मैं

मुझे अच्छा लगता है !

@iMacTia अरे, अगर आप मुझे कुछ संकेत दे सकते हैं कि कहां से शुरू करना है, तो मुझे ऐसा करने में मदद मिल सकती है।

धन्यवाद @philsturgeon , यह बहुत अच्छा होगा! मुझे इसके इर्द-गिर्द के मुख्य बिंदुओं का पुनर्कथन करने की अनुमति दें:

1. सभी परिवर्तनों को v1.0 शाखा के विरुद्ध करने की आवश्यकता होगी (क्योंकि वे पीछे की ओर असंगत होंगे)।
2. टाइमआउट प्रबंधन व्यवहार एडेप्टर में असंगत है, इसलिए हमें इसे मानकीकृत करने की आवश्यकता है।
3. सहमत व्यवहार निम्नलिखित है:
4. ओपन टाइमआउट के मामले में, हम एक ConnectionOpenTimeout त्रुटि उत्पन्न करेंगे जो ConnectionFailed से इनहेरिट होगी।
5. रीड टाइमआउट के मामले में, हम TimeoutError बढ़ाएंगे।

क्या मैं कुछ भूल गया?

क्या ConnectionOpenTimeout को डिफ़ॉल्ट फैराडे में जोड़ा जाएगा :: अनुरोध :: हैंडल किए गए अपवादों का पुनः प्रयास करें?

@mjhoy यह एक अच्छी बात है लेकिन फिलहाल कनेक्शन समस्याओं के मामले में

हालांकि, Faraday::Request::Retry विन्यास योग्य है इसलिए कुछ भी आपको ConnectionOpenTimeout या यहां तक ​​कि ConnectionFailed को उन अपवादों की सूची में जोड़ने से नहीं रोकता है जिन्हें आप संभालना चाहते हैं।

डिफ़ॉल्ट अपवादों की सूची में जोड़ने से पहले मैं कुछ और "समुदाय की राय" देखना चाहता हूं

हम कभी-कभी एपीआई एंडपॉइंट के साथ OpenTimeout त्रुटियों का सामना कर रहे हैं जिन्हें पुन: प्रयास करने की आवश्यकता है; यह ऊपर आपके Errno::ETIMEDOUT, Timeout::Error, Error::TimeoutError , और Net::OpenTimeout का एक उपवर्ग है Timeout::Error ; यह विशेष रूप से स्पष्ट नहीं था कि फैराडे उनके साथ अलग व्यवहार कर रहे थे। तो शायद दस्तावेज़ीकरण अद्यतन किया जाना चाहिए? किसी भी स्थिति में, हाँ, हमने मिडलवेयर को कॉन्फ़िगर किया है; मैं बस सोच रहा हूं कि डिफ़ॉल्ट समझ में आता है या नहीं।

@mjhoy आप यह कहने में सही हैं कि Timeout::Error में Net::OpenTimeout भी शामिल है, इसलिए वर्तमान कार्यान्वयन के साथ ऐसा लगता है कि ओपन टाइमआउट को भी पुनः प्रयास किया जाना चाहिए। इसके अलावा, सामान्य परिस्थितियों में एडेप्टर द्वारा Timeout::Error बचाया और फिर से उठाया जाता है, इसलिए अपवाद की सूची में इसकी उपस्थिति अनावश्यक या सिर्फ अतिरिक्त सुरक्षा के लिए हो सकती है।

एक बार जब हम अपवादों को रिफैक्टरिंग के साथ पूरा कर लेंगे, तो Net::OpenTimeout को एक नए अपवाद के रूप में उठाया जाएगा और जैसा कि मैंने अपनी टिप्पणी में कहा था, वर्तमान डिफ़ॉल्ट व्यवहार को बदल रहा है।

मेरा अब भी मानना ​​है कि डिफ़ॉल्ट का हिस्सा नहीं होना चाहिए, लेकिन काम करते समय यह निश्चित रूप से विचार करने के लिए कुछ है।

इसे बढ़ाने के लिए धन्यवाद

अरे, खेद है कि यह एक साल के लिए मेरी टीमों के बैकलॉग में पड़ा रहा और अब हमारी प्राथमिकताओं ने एक गुच्छा बदल दिया है। मैं इस मुद्दे पर कोई काम नहीं करूँगा, लेकिन शुभकामनाएँ!

@iMacTia क्या कोई इस बदलाव पर काम कर रहा है? मुझे इसे v2.0 के लिए लेने में कोई आपत्ति नहीं है।

हाय @ ragav0102 , समर्थन के लिए धन्यवाद!
इस पर अभी तक कोई काम नहीं कर रहा है, क्योंकि हम अभी भी v1.0 को दरवाजे से बाहर निकालने पर जोर दे रहे हैं।

हम निश्चित रूप से मदद की सराहना करेंगे, लेकिन हमारे पास अभी तक v2.0 के लिए कोई योजना नहीं है, इसलिए मैं यह नहीं बता सकता कि इसे कब जारी किया जाएगा, इसलिए आपके परिवर्तनों का उपयोग करने के लिए महीनों प्रतीक्षा करनी पड़ सकती है।

यदि आपको अपनी परियोजनाओं में से किसी एक में इसकी आवश्यकता है, तो शायद यह संभव नहीं है।
यदि आप अभी-अभी उत्तीर्ण हुए हैं और योगदान देना चाहते हैं, तो मेरा सुझाव है कि आप v1.0 के लिए निर्धारित कुछ चुनें क्योंकि इसे बहुत जल्द जारी किया जाएगा

समझ गया!