Runtime: सिंगलटन HttpClient DNS परिवर्तनों का सम्मान नहीं करता है

डिफ़ॉल्ट 60secs है और आप इसे जो चाहें मैन्युअल रूप से सेट कर सकते हैं। https://github.com/dotnet/corefx/blob/d0dc5fc099946adc1035b34a8b1f6042eddb0c75/src/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpHandler.cs#L76

मुझे नहीं लगता कि यह वही संपत्ति है। वह कनेक्शन टाइमआउट है, कनेक्शन लीजटाइमआउट नहीं।

जैसा कि https://msdn.microsoft.com/en-us/library/system.net.servicepoint.connectionleasetimeout.aspx में प्रलेखित है, इसे कुछ परिदृश्यों में समय-समय पर छोड़ दिया जाना चाहिए। लेकिन .NET कोर पर व्यवहार को बदलने का कोई स्पष्ट तरीका नहीं है।

@onovotny हाँ यह एक अजीब चीज है जो एक स्पष्ट सी कनेक्शन करने लगती है बंद करें । कोई कारण नहीं है कि यदि आप वास्तव में चाहते हैं तो मिडलवेयर के एक टुकड़े के रूप में लागू नहीं किया जा सकता है। यह सिर्फ एक HTTP शीर्षलेख है।

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

@onovotny , .NET कोर में कोई ServicePointManager वर्ग नहीं है। यह एक .NET Framework (डेस्कटॉप) समस्या की तरह लगता है। कृपया UserVoice या Connect में कोई समस्या खोलें।

@onovotny मूल मुद्दा, जैसा कि मैं समझता हूं कि, सर्वर की तरफ, कोई व्यक्ति DNS प्रविष्टि को अपडेट करना चाहता है, इसलिए A को होस्ट करने के लिए भविष्य के सभी अनुरोध नए IP पते पर जाते हैं। मेरी राय में सबसे अच्छा समाधान यह है कि जब उस DNS प्रविष्टि को बदल दिया जाता है, तो होस्ट ए पर एप्लिकेशन को एक सी कनेक्शन वापस करने के लिए कहा जाना चाहिए बंद करें । यह सभी ग्राहकों को कनेक्शन छोड़ने और एक नया स्थापित करने के लिए मजबूर करेगा। समाधान क्लाइंट पर टाइमआउट मान नहीं है, इसलिए क्लाइंट एक सी कनेक्शन भेजता है

यह कस्टम डीएनएस रिज़ॉल्वर का उपयोग करके स्टैक ओवरफ्लो

यह बिल्कुल मुद्दा है। @darrelmiller द्वारा प्रस्तावित समाधान उपयोग के मामले की समझ की कमी को प्रदर्शित करता है।

हम उदाहरण के स्वास्थ्य का मूल्यांकन करने के लिए Azure ट्रैफ़िक प्रबंधक का उपयोग करते हैं। वे छोटे टीटीएल के साथ डीएनएस के शीर्ष पर काम करते हैं। एक मेजबान जादुई रूप से नहीं जानता कि यह अस्वस्थ है और सी कनेक्शन जारी करना शुरू करें बंद करें । ट्रैफ़िक प्रबंधक केवल अस्वस्थ स्थिति का पता लगाता है और उसके अनुसार DNS रिज़ॉल्यूशन को समायोजित करता है। डिज़ाइन के अनुसार यह क्लाइंट और होस्ट के लिए पूरी तरह से ट्रांसपेरेंट है ... जैसा कि यह खड़ा है, एक ट्रैफिक मैनेजर द्वारा एक स्थिर HttpClient के साथ DNS (अनजाने में) को हल करने वाले एप्लिकेशन को कभी भी एक नया होस्ट प्राप्त नहीं होगा जब पहले से हल किया गया होस्ट अस्वस्थ हो जाता है।

नेटकोर 1.1 के रूप में मैं वर्तमान में इस सटीक समस्या का समाधान खोज रहा हूं। मैं वैसे भी एक नहीं देखता, मूल रूप से।

@ kudoz83 आप सही हैं, एक होस्ट को जादुई रूप से पता नहीं चलता है कि कब ट्रैफिक मैनेजर ने DNS रिज़ॉल्यूशन को समायोजित किया है, इसलिए मैंने ऐसा क्यों कहा

जब उस DNS प्रविष्टि को बदल दिया जाता है, तो होस्ट A पर एप्लिकेशन को बताया जाना चाहिए

यदि आपको विश्वास नहीं है कि किसी मूल सर्वर को सूचित करना व्यावहारिक है कि उसे c कनेक्शन वापस करना चाहिए बंद करें तो आपके

• क्लाइंट या मिडलवेयर से समय-समय पर कनेक्शन बंद करें और उन कनेक्शनों को फिर से खोलने की लागत का अनावश्यक रूप से भुगतान करें
• क्लाइंट को यह जानने के लिए एक सेवा का चुनाव करें कि उसे कनेक्शन कब रीसेट करना चाहिए।
• मिडलवेयर के एक टुकड़े का उपयोग करें जो यह जानने के लिए पर्याप्त स्मार्ट हो कि DNS कब स्विच किया गया है।

और मेरे बारे में उपयोग के मामले को समझ में नहीं आ रहा है। मूल मुद्दा एक ब्लॉग पोस्ट पर आधारित था जहां उपयोग का मामला उत्पादन और स्टेजिंग स्लॉट के बीच स्विच करने से संबंधित था और इसका स्वास्थ्य निगरानी से कोई लेना-देना नहीं था। हालांकि दोनों परिदृश्य DNS/स्लॉट स्विच की सूचनाएं प्राप्त करने में सक्षम होने से लाभान्वित हो सकते हैं।

AFAIK असफल होस्ट को सूचित करने का कोई तरीका नहीं है कि यह असफल रहा है? आम तौर पर इसका मतलब यह होगा कि यह किसी प्रकार की त्रुटि स्थिति में है। मूल पोस्ट विफलता परिदृश्यों के बारे में बात कर रही है।

Azure ट्रैफ़िक प्रबंधक को यहाँ समझाया गया है https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-monitoring

यह डीएनएस स्तर पर काम करता है और ग्राहकों और मेजबानों के लिए पारदर्शी है - डिजाइन द्वारा। DNS रिज़ॉल्यूशन के लिए ट्रैफ़िक मैनेजर के माध्यम से एक दूसरे के साथ संचार करने वाले Azure इंस्टेंसेस एक HttpClient के लिए DNS रिफ्रेश पर TTL सेट करने में सक्षम हुए बिना अचार में हैं।

जिस तरह से एचटीपी क्लाइंट वर्तमान में संचालित होता है वह माइक्रोसॉफ्ट की अपनी एज़ूर सेवा प्रसाद के साथ बाधाओं में प्रतीत होता है - जो कि संपूर्ण बिंदु है। उल्लेख नहीं करने के लिए, कोई भी समान सेवा (ईजी अमेज़ॅन रूट 53) ठीक उसी तरह काम करती है, और ठीक उसी तरह की छोटी डीएनएस टीटीएल निर्भरता है।

जाहिर है मुझे यह धागा मिला क्योंकि मैं इस मुद्दे से प्रभावित हूं। मैं केवल यह स्पष्ट करने की कोशिश कर रहा हूं कि DNS विफलता सफल होने के लिए केवल मनमाने ढंग से HttpClients (प्रदर्शन और जटिलता की कीमत पर) को फिर से बनाने के अलावा वर्तमान में एक आदर्श समाधान प्रतीत नहीं होता है।

AFAIK असफल होस्ट को सूचित करने का कोई तरीका नहीं है कि यह असफल रहा है?

यदि कोई "विफल" होस्ट किसी भी कोड को निष्पादित नहीं कर सकता है तो हमें HTTP स्थिति कोड 503 की आवश्यकता नहीं होगी क्योंकि एक मूल सर्वर इसे वापस करने में सक्षम नहीं होगा। ऐसे परिदृश्य हैं जहां एक असफल मेजबान अधिसूचना को संसाधित करने में सक्षम नहीं हो सकता है, लेकिन उन मामलों में शायद यह एक सक्रिय टीसीपी/आईपी कनेक्शन को बहुत लंबे समय तक खुला नहीं रखेगा।

जब अली ने मूल रूप से इस विषय को ट्विटर पर लाया, ब्लॉग पोस्ट लिखने से पहले, वह इस तथ्य के बारे में ठोस था कि एक ग्राहक अनुरोध करना जारी रखेगा और एक सर्वर से प्रतिक्रिया प्राप्त करेगा जिसे बदल दिया गया था।

मैं समझता हूं कि आपकी स्थिति अलग है और आप एक मूल सर्वर पर भरोसा नहीं कर सकते हैं जो किसी कनेक्शन को विश्वसनीय रूप से बंद करने में सक्षम है। मुझे यकीन नहीं है कि मैं समझता हूं कि आपकी स्थिति के लिए, आप 5XX प्रतिक्रियाओं का पता लगाने, कनेक्शन बंद करने और अनुरोध का पुन: प्रयास करने के लिए HttpMessageHandler का उपयोग क्यों नहीं कर सकते हैं। या इससे भी आसान, बस अपने वेब सर्वर को c onconnection: Close जब भी यह 5XX स्थिति कोड लौटाता है, वापस करने के लिए मना लें।

यह भी ध्यान देने योग्य है कि आप जिस व्यवहार से संबंधित हैं वह HttpClient में नहीं है। यह अंतर्निहित HttpHandler या उसके नीचे भी है, और उपयोग में HttpHandler के कई अलग-अलग कार्यान्वयन हैं। मेरी राय में, वर्तमान व्यवहार HTTP को काम करने के तरीके के अनुरूप है। मैं सहमत हूं कि जब कनेक्शन खुले होते हैं तो DNS सेटिंग्स अपडेट होने पर एक चुनौती होती है, लेकिन यह एक .net समस्या नहीं है। यह एक HTTP आर्किटेक्चर समस्या है। इसका मतलब यह नहीं है कि .net इस समस्या को कम करने के लिए कुछ नहीं कर सका।

मैं उत्सुक हूं कि आप क्या मानते हैं कि समाधान क्या होना चाहिए। क्या आपको लगता है कि कनेक्शन लीजटाइमआउट जैसा कुछ फिर से लागू किया जाना चाहिए जो समय-समय पर कनेक्शन को छोड़ देता है, भले ही कोई विफलता हुई हो या नहीं? या आपके पास कोई बेहतर उपाय है?

माफ़ करना,

मुझे कल जैसा लग रहा था, उतना जुझारू नहीं होना चाहिए था। दिन खराब चल रहा था।

ईमानदारी से मुझे पता नहीं है कि कैसे ConnectionLeaseTimeout कवर के नीचे काम करता है। वांछित कार्यक्षमता एचटीपी क्लाइंट के लिए कॉन्फ़िगर करने योग्य होगी ताकि क्लाइंट के निपटारे तक पिछले डीएनएस लुकअप को कैशिंग करने के विरोध में नए कनेक्शन स्थापित करने से पहले एक नया डीएनएस लुकअप किया जा सके। मुझे विश्वास नहीं है कि इसके लिए मौजूदा कनेक्शन को मारने की आवश्यकता है ...

@ kudoz83 कोई चिंता नहीं, हम सभी के पास ऐसे ही दिन होते हैं :-)

जो मैं समझता हूं कनेक्शनलीजटाइमआउट सचमुच एक टाइमर है जो समय-समय पर क्लाइंट साइड से निष्क्रिय कनेक्शन बंद कर देता है। इसे ServicePointManager में लागू किया गया है, जो कोर में मौजूद नहीं है। यह "निष्क्रिय कनेक्शन" टाइमआउट से अलग है जो एक निश्चित अवधि के लिए उपयोग नहीं किए जाने के बाद केवल एक कनेक्शन को बंद कर देता है।

एक Win32 कॉल होने की संभावना है जो DNS क्लाइंट कैश को फ्लश करने की अनुमति देगी। यह सुनिश्चित करेगा कि नए कनेक्शन DNS लुकअप करें। मैंने इसके लिए एक त्वरित खोज की, लेकिन यह नहीं मिला, लेकिन मुझे यकीन है कि यह कहीं न कहीं है।

विंडोज़ पर .net कोर में, HTTP कनेक्शन का प्रबंधन वास्तव में ओएस पर छोड़ दिया जाता है। आपको सबसे नज़दीकी Win32 API WinHttpOpen पर कॉल है https://github.com/dotnet/corefx/blob/master/src/System.Net.Http.WinHttpHandler/src/System/Net/Http/WinHttpHandler.cs# L718 कोई सार्वजनिक एपीआई नहीं है जो मुझे _sessionHandle के साथ कुछ भी करने के लिए मिल सके। आप जिस प्रकार के व्यवहार परिवर्तन की तलाश कर रहे हैं, उसे प्राप्त करने के लिए OS के लोगों को परिवर्तन करने की आवश्यकता होगी। कम से कम मैं इसे ऐसे ही समझता हूं।

क्या केवल DNS प्रविष्टियों पर बहुत कम TTL सेट करने के लिए Azure ट्रैफ़िक प्रबंधक प्राप्त करना आसान नहीं होगा? यदि आप लंबे समय तक चलने वाले कनेक्शन के बारे में चिंतित नहीं हैं, तो एक कम टीटीएल को एक मृत सर्वर के खिलाफ नए कनेक्शन स्थापित होने की संभावना को कम करना चाहिए।

WinHttpHandler के निर्माण के तरीके का उल्टा यह है कि हमें OS अपडेट के साथ HTTP / 2 जैसी चीजें मुफ्त में मिलती हैं। नकारात्मक पक्ष यह है कि हमें प्रबंधित कोड में बहुत अधिक नियंत्रण नहीं मिलता है।

@darrelmiller

[कनेक्शनलीजटाइमआउट] सर्विसपॉइंटमैनेजर में लागू किया गया है, जो कोर में मौजूद नहीं है।

ऐसा लगता है कि ServicePoint.ConnectionLeaseTimeout .Net Standard 2.0/.Net Core 1.2 में वापस आ रहा है। (हालांकि मुझे नहीं पता कि उदाहरण के लिए WinHttpHandler कनेक्शन इसका पालन करेंगे।)

मुझे लगता है कि यहां कुछ गलत संचार है: डीएनएस टीटीएल पूरी तरह से HTTP/टीसीपी कनेक्शन जीवनकाल से असंबंधित हैं।

नए HTTP कनेक्शन DNS लुकअप करते हैं और दिए गए होस्ट पते से कनेक्ट होते हैं। एक ही कनेक्शन पर कई HTTP अनुरोध किए जा सकते हैं लेकिन एक बार HTTP कनेक्शन (और अंतर्निहित टीसीपी कनेक्शन) खोलने के बाद फिर से DNS लुकअप नहीं होता है।

यह सही व्यवहार है इसलिए भले ही आप एक कनेक्शन पर 1000 अनुरोध करते हैं जो दिनों तक चलता है, DNS रिज़ॉल्यूशन कोई मायने नहीं रखता क्योंकि कनेक्शन नहीं बदला है। यदि आप एक नए HTTP कनेक्शन पर एक नया HTTP अनुरोध

इस DNS रिफ्रेश का HttpClient से कोई लेना-देना नहीं है, जो डिफ़ॉल्ट रूप से केवल HttpClientHandler का उपयोग करता है (जो स्वयं HttpWebRequest सॉकेट स्टैक का उपयोग करता है) और किसी भी DNS रिज़ॉल्यूशन को उस स्टैक द्वारा नियंत्रित किया जाता है। ServicePointManager उस स्टैक में ServicePoint ऑब्जेक्ट्स का प्रबंधन करता है जो एक विशिष्ट होस्ट से कनेक्शन होते हैं। ServicePointManager DNS खोज जो आप ठीक कर सकते हैं में से कुछ न्यूनतम क्लाइंट-साइड संचय करता है।

डिफ़ॉल्ट सेटिंग्स का मतलब दक्षता के लिए कनेक्शन अनिश्चित काल तक खुला रहना है। यदि कनेक्टेड होस्ट अनुपलब्ध हो जाता है, तो कनेक्शन स्वचालित रूप से टूट जाएगा, जिससे एक नए DNS लुकअप के साथ एक नया कनेक्शन हो जाएगा, हालांकि DNS TTL किसी भी नए कनेक्शन का कारण नहीं बनेंगे। यदि आपको इसकी आवश्यकता है, तो आपको इसे अपने ऐप में कोड करना होगा।

यदि आप एक और DNS लुकअप करना चाहते हैं, तो आपको क्लाइंट पर कनेक्शन रीसेट करना होगा। आप टीसीपी कनेक्शन के अधिकतम जीवनकाल को मजबूर कर सकते हैं, connection: close हेडर भेज सकते हैं या केवल HttpClient या अंतर्निहित ServicePoint निपटान कर सकते हैं। आप Dns.GetHostAddresses साथ DNS रिज़ॉल्यूशन भी कर सकते हैं और अपने HTTP अनुरोधों के लिए इसके बजाय IP पते का उपयोग कर सकते हैं।

उम्मीद है कि यह मदद करता है, अगर मैं इस पर बंद हूं तो कृपया मुझे बताएं।

@मणिगंधम

मुझे लगता है कि यहां कुछ गलत संचार है: डीएनएस टीटीएल पूरी तरह से HTTP/टीसीपी कनेक्शन जीवनकाल से असंबंधित हैं।

हाँ डीएनएस टीटीएल काफी असंबंधित हैं, लेकिन पूरी तरह से नहीं।

नए HTTP कनेक्शन DNS लुकअप करते हैं और दिए गए होस्ट पते से कनेक्ट होते हैं।

हां यह सही है। लेकिन विंडोज़ में एक स्थानीय डीएनएस कैश है जो टीटीएल का सम्मान करता है। यदि टीटीएल अधिक है और डीएनएस सर्वर ने डीएनएस रिकॉर्ड को बदल दिया है, तो डीएनएस रिकॉर्ड के क्लाइंट कैशिंग के कारण पुराने आईपी पते के खिलाफ नया कनेक्शन खोला जाएगा। क्लाइंट DNS कैश को फ्लश करना ही इसका एकमात्र समाधान है जिसके बारे में मुझे जानकारी है।

एक ही कनेक्शन पर कई HTTP अनुरोध किए जा सकते हैं लेकिन एक बार HTTP कनेक्शन (और अंतर्निहित टीसीपी कनेक्शन) खोलने के बाद फिर से DNS लुकअप नहीं होता है।

फिर से सही। एक उत्पादन/स्टेजिंग स्वैप में जहां स्वैप आउट सर्वर अभी भी प्रतिक्रिया दे रहा है, इससे पुराने सर्वर पर जाने के लिए भविष्य के कई अनुरोध होंगे, जो खराब है। हालांकि, सबसे हालिया बातचीत उस परिदृश्य के बारे में रही है जहां एक सर्वर विफल हो जाता है और ट्रैफिक मैनेजर एक नए सर्वर पर बदल जाता है। विफल सर्वर से मौजूदा कनेक्शन का क्या होता है अज्ञात है। यदि यह एक गंभीर हार्डवेयर विफलता है, तो एक अच्छा मौका है कि कनेक्शन छोड़ दिया जाएगा। यह क्लाइंट को एक कनेक्शन फिर से स्थापित करने के लिए मजबूर करेगा और यही वह जगह है जहां कम टीटीएल उपयोगी है। यदि हालांकि, सर्वर विफलता सर्वर को नहीं तोड़ती है और यह केवल 5XX प्रतिक्रियाएं देता है तो सर्वर के लिए सी कनेक्शन वापस करने के लिए यह उपयोगी होगा

इस DNS रीफ्रेश का HttpClient से कोई लेना-देना नहीं है, जो डिफ़ॉल्ट रूप से HttpClientHandler का उपयोग करता है (जो स्वयं HttpWebRequest सॉकेट स्टैक का उपयोग करता है)

हां और ना। नेट कोर पर, HttpClientHandler को फिर से लिखा गया है और अब HttpWebRequest का उपयोग नहीं करता है और इसलिए ServicePointManager का उपयोग नहीं करता है। इसलिए इस मुद्दे का कारण।

मैंने आईआईएस पर नजदीकी नजर डाली और सी कनेक्शन के साथ आने के लिए 5XX प्रतिक्रियाएं प्राप्त करने का कोई तरीका प्रतीत नहीं होता है बंद करें । उस जादू को करने के लिए एक HttpModule को लागू करना आवश्यक होगा।

एक एफवाईआई के रूप में, यहां इस मुद्दे को कवर करने वाली एक संबंधित पोस्ट और एक अंतरिम समाधान है। एचटीपी क्लाइंट से सावधान रहें

या तो ServicePointManager को .NET कोर में लाया जाना चाहिए

जबकि हम प्लेटफ़ॉर्म समता के लिए ServicePointManager और HttpWebRequest लाए हैं, यह .Net Core में अधिकांश कार्यक्षमता का समर्थन नहीं करता है क्योंकि अंतर्निहित स्टैक WinHTTP या कर्ल को हल करता है जो उन्नत नियंत्रण नॉब्स को उजागर नहीं करता है।

HttpClient को नियंत्रित करने के लिए ServicePointManager का उपयोग करना वास्तव में HttpWebRequest और .Net Framework पर प्रबंधित HTTP स्टैक का उपयोग करने पर एक दुष्प्रभाव है। चूंकि WinHttpHandler/CurlHandler का उपयोग .Net Core पर किया जाता है, SPM का HttpClient इंस्टेंस पर कोई नियंत्रण नहीं होता है।

या समान समकक्ष कार्यक्षमता को किसी अन्य तरीके से सक्षम किया जाना चाहिए।

ये रहा WinHTTP टीम का जवाब:

1. सुरक्षा कारणों से, जबकि क्लाइंट अनुरोध भेजता रहता है और _सक्रिय कनेक्शन होते हैं_, WinHTTP गंतव्य IP का उपयोग करना जारी रखेगा। इन कनेक्शनों के सक्रिय रहने के समय को सीमित करने का कोई तरीका नहीं है।
2. यदि दूरस्थ समापन बिंदु के सभी कनेक्शन सर्वर द्वारा बंद कर दिए गए थे, तो _new_ कनेक्शन DNS को क्वेरी करके और इस प्रकार नए IP की ओर बनाए जाएंगे।

ग्राहकों को अगले आईपी के लिए बाध्य करने के लिए, एकमात्र व्यवहार्य समाधान यह सुनिश्चित करना है कि सर्वर नए कनेक्शन को अस्वीकार कर देता है और मौजूदा लोगों को बंद कर देता है (पहले से ही इस थ्रेड पर उल्लेख किया गया है)।
एटीएम प्रलेखन से मैं जो समझता हूं, वह वही है: GET अनुरोधों के आधार पर पता लगाया जाता है जो 4 बार विफल रहता है (गैर -200 प्रतिक्रियाएं) जिस स्थिति में सर्वर द्वारा कनेक्शन बंद कर दिया जाएगा।

अन्य नेटवर्क उपकरण उपकरणों को देखते हुए जो स्वयं DNS को कैशिंग कर रहे हैं (उदाहरण के लिए होम राउटर/एपी) मैं कम-विलंबता, उच्च उपलब्धता तकनीक के समाधान के रूप में DNS विफल-ओवर की अनुशंसा नहीं करता। यदि यह आवश्यक है, तो नियंत्रित विफलता के लिए मेरी सिफारिश एक समर्पित एलबी (हार्डवेयर या सॉफ्टवेयर) होगी जो जानता है कि कैसे ठीक से नाली-रोकना है।

जैसा कि यह खड़ा है, एक ट्रैफ़िक प्रबंधक द्वारा एक स्थिर HttpClient के साथ DNS (अनजाने में) को हल करने वाले एप्लिकेशन को कभी भी एक नया होस्ट प्राप्त नहीं होगा जब पहले से हल किया गया होस्ट अस्वस्थ हो जाता है।

जैसा कि ऊपर उल्लेख किया गया है, यदि अस्वस्थता से आपका मतलब है कि सर्वर एक HTTP त्रुटि कोड देता है और जब आप DNS TTL की समय सीमा समाप्त होते देखते हैं, तो यह TCP कनेक्शन बंद कर देता है, यह वास्तव में एक बग है।

कृपया अपने परिदृश्य का अधिक विस्तार से वर्णन करें:

1. फ़ेलओवर के दौरान, क्लाइंट-मशीन का DNS कैश और TTL क्या होता है। मशीन क्या सोचती है कि टीटीएल क्या है और आधिकारिक एनएस के टीटीएल की तुलना करने के लिए आप ipconfig /showdns और nslookup -type=soa <domain_name> का उपयोग कर सकते हैं।
2. क्या रिमोट सर्वर के लिए सक्रिय कनेक्शन हैं? आप कनेक्शन और प्रक्रियाओं को देखने के लिए netstat /a /n /b का उपयोग कर सकते हैं।
3. रेप्रो बनाने से हमें बहुत मदद मिलेगी: कृपया कोई भी उपलब्ध जानकारी संलग्न करें जैसे: नेट कोर/फ्रेमवर्क का संस्करण, क्लाइंट/सर्वर के लिए कोड, नेटवर्क ट्रेस, रिमोट डीएनएस एलबी/ट्रैफिक मैनेजर शामिल इत्यादि।

यदि आप किसी मशीन से जुड़ते हैं और टीसीपी/एचटीटीपी कनेक्शन काम करना जारी रखता है, तो आपको किसी बिंदु पर यह क्यों मान लेना चाहिए कि सर्वर अब उपयुक्त नहीं है।
मुझे लगता है कि Azure पक्ष में सुधार की गुंजाइश है। उदाहरण के लिए, जब मशीनें अस्वस्थ होती हैं या वातावरण की अदला-बदली होती है, तो मौजूदा कनेक्शन बंद किए जा सकते हैं।

या बस ... अंतर्निहित ServicePoint . का निपटान करें

@मणिगंधम कैसे? यह डिस्पोजेबल नहीं है और एकमात्र प्रासंगिक विधि जो मैं देख सकता हूं वह है CloseConnectionGroup जिसका आप वास्तव में उपयोग नहीं कर सकते क्योंकि समूह का नाम एक कार्यान्वयन विवरण है (वर्तमान में हैंडलर का कुछ हैश)। साथ ही, मुझे यकीन नहीं है कि क्या होगा यदि आपने सर्विसपॉइंट का निपटान करने का प्रयास किया, जबकि HttpClient इसका उपयोग कर रहा था (विशेष रूप से समवर्ती)।

@ohadschn

.NET कोर 2.0 ServicePoint कक्षाओं और कार्यक्षमता को वापस लाता है: https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepoint?view=netcore-2.0

आप सक्रिय कनेक्शन के रीसेट होने से पहले अधिकतम समय सीमा निर्धारित करने के लिए कनेक्शन लीज़ टाइमआउट का उपयोग करके वापस जा सकते हैं।

HttpClient अनुरोध प्रगति पर होने पर कनेक्शन बंद करने के बारे में कुछ भी आकर्षक नहीं है, यह वही होगा जैसे आप इंटरनेट ब्राउज़ करते समय कनेक्टिविटी खो देते हैं। या तो अनुरोध इसे कभी नहीं बनाता है या यह करता है और आपको प्रतिक्रिया वापस नहीं मिलती है - दोनों को http त्रुटियों को वापस करना चाहिए और आपको उन्हें अपने आवेदन में संभालना होगा।

कनेक्शन लीज टाइमआउट सेटिंग के साथ आप यह सुनिश्चित कर सकते हैं कि यह अनुरोध भेजे जाने के बाद ही किया जाता है और समय सीमा से पहले अगले एक से पहले रीसेट कर दिया जाता है।

.NET कोर 2.0 सर्विसपॉइंट कक्षाओं और कार्यक्षमता को वापस लाता है: https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepoint?view=netcore-2.0
आप सक्रिय कनेक्शन के रीसेट होने से पहले अधिकतम समय सीमा निर्धारित करने के लिए कनेक्शन लीज़ टाइमआउट का उपयोग करके वापस जा सकते हैं।

दरअसल, यह पूरी तरह से कार्यक्षमता को वापस नहीं लाता है। एपीआई सतह वापस आ गई। लेकिन यह मूल रूप से एक नो-ऑप है क्योंकि HTTP स्टैक उस ऑब्जेक्ट मॉडल का उपयोग नहीं करते हैं।

सीसी: @stephentoub @geoffkizer

मैं इस विषय में कई प्रतिभागियों को इस विषय में "सपना टीम" के रूप में मानता हूं, फिर भी मुझे अभी भी यकीन नहीं है कि आज हमारे पास जो सर्वोत्तम अभ्यास दिए गए हैं, उन पर कोई सहमति बन गई है। इस समूह से कुछ प्रमुख बिंदुओं पर निर्णायक उत्तर प्राप्त करना बहुत अच्छा होगा।

मान लें कि मेरे पास एक सामान्य उद्देश्य HTTP लाइब्रेरी है जो कई प्लेटफार्मों को लक्षित करती है, जिनमें से सभी ServicePointManager समर्थन नहीं करते हैं, और मैं ऐसा व्यवहार प्रदान करने का प्रयास कर रहा हूं जो डिफ़ॉल्ट रूप से सर्वोत्तम प्रथाओं के अनुसार HttpClient उदाहरणों को स्मार्ट तरीके से प्रबंधित करता है। मुझे समय से पहले पता नहीं है कि मेजबानों को क्या कहा जाएगा, अकेले रहने दें कि क्या वे डीएनएस परिवर्तन/सी कनेक्शन के संबंध में अच्छी तरह से व्यवहार कर रहे हैं बंद करें ।

1. मैं HttpClient उदाहरणों को बेहतर तरीके से कैसे प्रबंधित करूं? एक प्रति समापन बिंदु? एक प्रति होस्ट/स्कीमा/पोर्ट? सचमुच एक सिंगलटन कुल? (मुझे संदेह है कि, चूंकि उपभोक्ता डिफ़ॉल्ट हेडर आदि का लाभ उठाना चाहते हैं)

2. मैं इस DNS समस्या से सबसे प्रभावी ढंग से कैसे निपटूं? 1 मिनट के बाद उदाहरणों का निपटान करें? इसे "अत्यधिक असंभव" के रूप में मानें और डिफ़ॉल्ट रूप से कोई निपटान व्यवहार प्रदान न करें?

(एक काल्पनिक स्थिति बीटीडब्ल्यू नहीं; मैं अभी इन सटीक प्रश्नों के साथ कुश्ती कर रहा हूं।)

धन्यवाद!

मुझे ड्रीम टीम ट्राउटआउट में भी आमंत्रित नहीं किया जाएगा, लेकिन मेरे पास आपकी सिंगलटन HttpClient टिप्पणी के बारे में एक अंतर्दृष्टि है। सबसे पहले, आप अलग-अलग हेडर और पते निर्दिष्ट करने के लिए हमेशा SendAsync विधि का उपयोग कर सकते हैं, ताकि आप इसे अपनी कक्षा के साथ लपेट सकें जो HttpClient समान साझा डेटा प्रदान करता है (उदाहरण के लिए डिफ़ॉल्ट शीर्षलेख, आधार पता) एक ही क्लाइंट को कॉल करना समाप्त होता है। लेकिन इससे भी बेहतर, आप कई HttpClient उदाहरण बना सकते हैं जो सभी समान HttpClientHandler साझा करते हैं: https://github.com/dotnet/corefx/issues/5811।

जहाँ तक DNS मुद्दे का सवाल है, यहाँ सर्वसम्मति से ऐसा प्रतीत होता है:

ग्राहकों को अगले आईपी के लिए बाध्य करने के लिए, एकमात्र व्यवहार्य समाधान यह सुनिश्चित करना है कि सर्वर नए कनेक्शन को अस्वीकार कर देता है और मौजूदा को बंद कर देता है

यदि यह आपके लिए व्यवहार्य नहीं है, तो डैरेल मिलर ने यहां कुछ और विकल्प सुझाए: https://github.com/dotnet/corefx/issues/11224#issuecomment -270498159।

@ohadschn धन्यवाद, और उम्मीद है कि मैं विषय से बहुत दूर नहीं जा रहा हूं, लेकिन क्या कई मेजबानों के बीच एक ही HttpClient (या HttpClientHandler) को साझा करने के लिए कोई _benefit_ है? मैं गलत हो सकता था लेकिन मुझे ऐसा लगता है कि एक नए होस्ट का अर्थ है नया DNS लुकअप, नया कनेक्शन, नया सॉकेट। क्या TIME_WAIT में एक सॉकेट को पुनः प्राप्त किया जा सकता है और एक अलग होस्ट के लिए फिर से तैयार किया जा सकता है? मैंने नहीं माना था, लेकिन हम निश्चित रूप से अपनी विशेषज्ञता की सीमा तक पहुंच रहे हैं। यदि ऐसा हो सकता है, तो शायद यह कई मेजबानों के साथ भी HttpClient सिंगलटन का उपयोग करने का लाभ है?

DNS सलाह के बारे में, मुझे ऐसा लगा कि सर्वसम्मति की सबसे अधिक कमी है, और समझ में आता है। यह सुनिश्चित करना कि सर्वर सही ढंग से व्यवहार करता है, व्यवहार्य नहीं है यदि आपके पास उस छोर पर क्या हो रहा है, इसका नियंत्रण नहीं है। मैं कुछ ऐसा डिज़ाइन कर सकता हूँ जहाँ उदाहरणों का समय-समय पर निपटान किया जाता है। सवाल यह है कि क्या यह ज्यादातर मामलों में ट्रेड-ऑफ के लायक है। मुझे लगता है कि निर्णय लेने के लिए काफी हद तक मेरे ऊपर है। :)

मेरे लिए समान HttpClient [ Handler ] साझा करने का सबसे स्पष्ट लाभ सादगी है। आपको होस्ट और क्लाइंट के बीच मैपिंग जैसी चीज़ें नहीं रखनी होंगी। मैं TIME_WAIT सामग्री के बारे में नहीं जानता, वास्तव में मेरी विशेषज्ञता भी नहीं।

जब आप सर्वर को नियंत्रित नहीं करते हैं तो DNS के संबंध में, आपने एक संभावित दृष्टिकोण का उल्लेख किया है। आप एक तंत्र भी लागू कर सकते हैं जो समय-समय पर डीएनएस से पूछताछ करता है और वास्तविक परिवर्तन होने पर ही उदाहरणों का निपटान करता है ...

जबकि दिए गए उत्तर जो निर्दिष्ट करते हैं कि सर्वर-साइड पर क्या होना चाहिए, एक आदर्श दुनिया के लिए सटीक हैं, वास्तविक दुनिया में डेवलपर्स के पास अक्सर पूर्ण सर्वर-साइड स्टैक का नियंत्रण नहीं होता है, जिसके साथ वे संचार कर रहे हैं। उस संबंध में मुझे वास्तव में कनेक्शन लीज टाइमआउट की अवधारणा पसंद है, क्योंकि यह जॉन और जेन डोवेलपर के दैनिक जीवन की वास्तविकताओं के लिए एक रियायत है।
किसी ने .NET कोर पर इस तरह के टाइमआउट को लागू करने के लिए मिडलवेयर लिखने का सुझाव दिया। क्या यह वर्ग NodaTime और System.Collections.Immutable पर आधारित काम करेगा?

    public class ConnectionLeaseTimeoutHandler : DelegatingHandler
    {
        private static string GetConnectionKey(Uri requestUri) => $"{requestUri.Scheme}://{requestUri.Host}:{requestUri.Port}";

        private readonly IClock clock;
        private readonly Duration leaseTimeout;
        private ImmutableDictionary<string, Instant> connectionLeases = ImmutableDictionary<string, Instant>.Empty;

        public ConnectionLeaseTimeoutHandler(HttpMessageHandler innerHandler, IClock clock, Duration leaseTimeout)
            : base(innerHandler)
        {
            this.clock = clock;
            this.leaseTimeout = leaseTimeout;
        }

        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            string key = GetConnectionKey(request.RequestUri);
            Instant now = clock.GetCurrentInstant();

            Instant leaseStart = ImmutableInterlocked.GetOrAdd(ref connectionLeases, key, now);

            if (now - leaseStart > leaseTimeout)
            {
                request.Headers.ConnectionClose = true;
                ImmutableInterlocked.TryRemove(ref connectionLeases, key, out leaseStart);
            }

            return base.SendAsync(request, cancellationToken);
        }
    }

@snboisen मुझे लगता है कि यह सही लगता है लेकिन मुझे उस पर मत पकड़ो। :)

मेरे लिए बड़ा सवाल यह है कि क्या Connection: close हेडर भेजना भी एक व्यवहार्य समाधान है। यह यहाँ दोहराने लायक है कि @darrelmiller ने ब्लॉग पोस्ट की टिप्पणियों में क्या कहा जिसने इस धागे को प्रेरित किया:

कनेक्शन लीज टाइमआउट एक अजीब जानवर है, जिसके बारे में मुझे तब तक पता नहीं था जब तक कि ओरेन ने आज इसका उल्लेख नहीं किया। यह आउटगोइंग अनुरोधों को सी ऑननेक्शन शामिल करने का कारण होगा बंद करें , जिससे सर्वर द्वारा प्रतिक्रिया भेजने के बाद कनेक्शन समाप्त हो जाएगा। यह समझ में आता है कि इसे डिफ़ॉल्ट से अनंत पर क्यों सेट किया गया है क्योंकि क्लाइंट सक्रिय रूप से अनुरोध करने पर कनेक्शन को बंद करने के लिए मजबूर करने का यह एक अजीब तरीका है।

मैं डैरेल की राय का सम्मान करता हूं और यह इस पूरे दृष्टिकोण को हैकिश लगता है। दूसरी ओर, मैं सहमत हूं कि एक डेवलपर को क्या करना चाहिए, जिसके पास सर्वर साइड पर क्या हो रहा है, इसका नियंत्रण नहीं है? अगर यह _कभी-कभी_ काम करता है, तो शायद यह हमारे पास सबसे अच्छा विकल्प है? यह निश्चित रूप से एचटीपी क्लाइंट्स को समय-समय पर निपटाने या समय-समय पर डीएसएन लुकअप करने से "सस्ता" है।

क्या इस मुद्दे के लिए कोई Azure टिकट खुला है?
मेरे दृष्टिकोण से ऐसा लगता है कि आप सभी जिस तरह से इसे Azure के ट्रैफ़िक प्रबंधक में लागू किया गया है, उसे हल करने का प्रयास कर रहे हैं।
मैं एक Azure उपयोगकर्ता नहीं हूं, इसलिए मैं इसे दूर से देखता हूं, इसके हुप्स से कूदने के लिए कम इच्छुक महसूस करता हूं।

@tmds मैंने एक नहीं देखा है, लेकिन जैसा कि अन्य ने उल्लेख किया है, यह केवल Azure ट्रैफ़िक प्रबंधक से अधिक से संबंधित है: AWS की एक समान अवधारणा है और इसके स्टेजिंग/प्रोडक्शन स्लॉट स्वैपिंग के साथ Azure ऐप सेवा है। और मैं शर्त लगाता हूं कि अन्य क्लाउड प्रदाता भी इस स्वैपिंग तंत्र के समान कुछ प्रदान करते हैं।

@snboisen क्या आप कह रहे हैं कि AWS और अन्य क्लाउड प्रदाता (जो?) भी इन सुविधाओं को लागू करने के लिए DNS टाइमआउट का उपयोग कर रहे हैं?

@tmds AWS के लिए, हाँ, कम से कम विफलता के लिए: https://aws.amazon.com/route53/faqs/#adjust_ttl_to_use_failover
मैं अन्य क्लाउड प्रदाताओं के बारे में नहीं जानता, लेकिन ऐसा लगता है कि कुछ ऐसा भी करते हैं।

@tmds AWS के लिए, हाँ, कम से कम विफलता के लिए: https://aws.amazon.com/route53/faqs/#adjust_ttl_to_use_failover
मैं अन्य क्लाउड प्रदाताओं के बारे में नहीं जानता, लेकिन ऐसा लगता है कि कुछ ऐसा भी करते हैं।

यहां दो समस्याग्रस्त परिदृश्य हैं:

• क्लाइंट एक सर्वर से जुड़ा है जो अब नहीं है
• क्लाइंट एक सर्वर से जुड़ा है जो अब सॉफ़्टवेयर का पुराना संस्करण चला रहा है

DNS फेलओवर पहले से संबंधित है। DNS (AWS, Azure, ... में) से अगम्य सर्वरों को निकालना उचित है।
क्लाइंट पर इसका पता लगाने का उचित तरीका टाइमआउट मैकेनिज्म है। मुझे यकीन नहीं है कि एचटीपी क्लाइंट पर ऐसी कोई संपत्ति है (एक स्थापित कनेक्शन पर अधिकतम उत्तर टाइमआउट)।
प्रोटोकॉल स्तर पर, नए वेबसोकेट और http2 प्रोटोकॉल कनेक्शन की जीवंतता की जांच के लिए पिंग/पोंग संदेशों को परिभाषित करते हैं।

जब मैं Azure के साथ कोई समस्या खोलने का सुझाव देता हूं, तो यह दूसरे परिदृश्य के लिए होता है।
कोई कारण नहीं है कि क्लाइंट को एक कार्यशील कनेक्शन बंद करना चाहिए। यदि सर्वर अब उपयुक्त नहीं है, तो क्लाइंट को डिस्कनेक्ट कर दिया जाना चाहिए और सर्वर को पहुंच से बाहर किया जाना चाहिए।
मुझे AWS ब्लू/ग्रीन परिनियोजन पर एक अच्छा डॉक्टर मिला: https://d0.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf।
यह कई तकनीकों को सूचीबद्ध करता है। DNS का उपयोग करने वालों के लिए यह _DNS TTL जटिलताओं_ का उल्लेख करता है। उन लोगों के लिए जो लोड बैलेंसर का उपयोग करते हैं _कोई DNS जटिलताएं नहीं_।

@tmds लिंक के लिए धन्यवाद, यह बहुत दिलचस्प है।

मुझे आश्चर्य है कि डीएनएस टीटीएल बनाम लोड बैलेंसर का उपयोग करना कितना आम है। उत्तरार्द्ध सामान्य रूप से अधिक विश्वसनीय समाधान की तरह लगता है।

HttpClient माध्यम से संचार करने वाली Azure ऐप सेवाओं में 2 अलग-अलग API ऐप्स के साथ काम करते समय कुछ समान व्यवहार का अनुभव किया। हमने अपने लोड परीक्षणों में लगभग 250 अनुरोधों पर ध्यान दिया, हमें टाइमआउट मिलना शुरू हो गया और "एक कनेक्शन स्थापित नहीं किया जा सका" HttpRequestException - इससे कोई फर्क नहीं पड़ता कि यह समवर्ती उपयोगकर्ता थे, या अनुक्रमिक अनुरोध थे।

जब हमने प्रत्येक अनुरोध में HttpClient का निपटान सुनिश्चित करने के लिए using ब्लॉक में स्विच किया, तो हमें इनमें से कोई भी अपवाद नहीं मिला। प्रदर्शन हिट, यदि कोई हो, सिंगलटन से using सिंटैक्स के लिए नगण्य था।

जब हमने प्रत्येक अनुरोध में HttpClient का निपटान सुनिश्चित करने के लिए using ब्लॉक पर स्विच किया, तो हमें इनमें से कोई भी अपवाद नहीं मिला। प्रदर्शन हिट, यदि कोई हो, सिंगलटन से using सिंटैक्स के लिए नगण्य था।

यह प्रदर्शन के बारे में जरूरी नहीं है, यह टीसीपी कनेक्शन लीक नहीं करने और SocketException s प्राप्त करने के बारे में है।

एमएसडीएन से :

एचटीपी क्लाइंट को एक बार तत्काल चालू करने और किसी एप्लिकेशन के पूरे जीवन में पुन: उपयोग करने का इरादा है। विशेष रूप से सर्वर अनुप्रयोगों में, प्रत्येक अनुरोध के लिए एक नया HttpClient उदाहरण बनाने से भारी भार के तहत उपलब्ध सॉकेट की संख्या समाप्त हो जाएगी। इसके परिणामस्वरूप SocketException त्रुटियाँ होंगी।

साथ ही, देखें https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

@khellang लिंक के लिए धन्यवाद (और SocketException s पर स्पष्टीकरण, मुझे निश्चित रूप से वहां एक गलतफहमी थी) - मैं उस पोस्ट और 3 या 4 अन्य पोस्टों में इसी सटीक चीज़ को रेखांकित कर रहा हूं।

मैं समझता हूं कि एक एकल-तत्काल इरादा है, लेकिन जब हम इसे Azure ऐप सेवाओं में उपयोग कर रहे हैं, तो हम काफी मामूली लोड (ऊपर उल्लिखित, 250 अनुक्रमिक अनुरोध) के तहत लगातार HttpRequestExceptions मार रहे हैं। जब तक कोई अन्य समाधान न हो, HttpClient को निपटाना वह समाधान है जिसे हमें इन सुसंगत अपवादों में भाग लेने से बचने के लिए लागू करना था।

मैं यह सोचते हैं रहा हूँ एक "अधिक सही" समाधान इन अपवादों को पकड़ने के लिए किया जाएगा, सभी लंबित अनुरोध को स्पष्ट रूप से निपटाने रद्द HttpClient , फिर से इन्स्तांत HttpClient , और अनुरोधों के सभी पुनः प्रयास करें।

ऐसा लगता है कि कुछ के लिए कुछ गड़बड़ है

एक बार तत्काल और आवेदन के पूरे जीवन में पुन: उपयोग करने का इरादा है

हम एक क्लीनर समाधान पसंद करेंगे, लेकिन ऐसा लगता है कि यह हमारे कोड के साथ कुछ गलत नहीं है, बल्कि ढांचे के साथ एक सीमा है। मैं गलत होने से अधिक खुश हूं, मुझे बस कुछ मार्गदर्शन की आवश्यकता है कि हम इसका उपयोग कैसे कर सकते हैं और इन मुद्दों का सामना नहीं कर सकते।

@snboisen मैंने आपके कनेक्शन

मुझे एचटीपी क्लाइंट इंस्टेंस द्वारा उपयोग में आने वाले प्रत्येक व्यक्तिगत कनेक्शन को "करीबी" जारी करने का कोई तरीका नहीं पता है। यह निश्चित रूप से आदर्श होगा, लेकिन मैं जो करने जा रहा हूं वह एचटीपी क्लाइंट के लिए GetOrCreate() फ़ैक्टरी विधि का उपयोग करना है और सभी नए कनेक्शन बनाए जाने के लिए हर 120 सेकंड में एक नया एचटीपी क्लाइंट इंस्टेंस बनाना है। मुझे यकीन नहीं है कि कनेक्शन बंद करने के लिए सभी अनुरोध समाप्त होने के बाद पुराने एचटीपी क्लाइंट इंस्टेंस के निपटान के बारे में कैसे जाना है, लेकिन मुझे लगता है कि .NET इसका ख्याल रखता है क्योंकि प्रति अनुरोध एक नया एचटीपी क्लाइंट इंस्टेंस बनाने में कभी भी कोई समस्या नहीं होती है।

एक साइड नोट के रूप में, मेरा मानना ​​​​है कि क्लाइंट पर रीफ्रेश होना है। सर्वर DNS परिवर्तनों और न ही किसी मिडलवेयर को संप्रेषित करने के लिए ज़िम्मेदार नहीं हो सकता है। डीएनएस का उद्देश्य ऐसी जिम्मेदारी को ऑफसेट करना है ताकि आप किसी क्लाइंट और सर्वर के बीच समन्वय के बिना किसी भी समय आईपी को बदल सकें और न केवल एक आईपी के लिए एक अनुकूल नाम प्रदान कर सकें। सही उपयोग का मामला एक एडब्ल्यूएस लोचदार आईपी पता है। परिवर्तन केवल DNS में दिखाई देता है। एडब्ल्यूएस को ईसी 2 इंस्टेंस पर चल रहे आपके वेब सर्वर से "करीबी" शीर्षलेख भेजने के बारे में पता नहीं चल रहा है। एडब्ल्यूएस को एक ईसी 2 इंस्टेंस के ऊपर बैठे प्रत्येक वेब सर्वर के बारे में पता नहीं होगा जिसे वे प्रबंधित करते हैं। पुराने सर्वर के लिए "क्लोज़" हेडर नहीं भेजने का परिदृश्य नया सर्वर परिनियोजन है जहाँ ठीक उसी सॉफ़्टवेयर को नए सर्वर पर तैनात किया जा रहा है जिसमें DNS द्वारा स्विच किए गए सभी ट्रैफ़िक हैं। पुराने सर्वर पर कुछ भी नहीं बदलना चाहिए, खासकर यदि आपको वापस स्विच करना है। DNS के साथ एक ही स्थान पर सब कुछ सुचारू रूप से बदला जाना चाहिए।

यहां चर्चा किए गए बड़े मुद्दों के बावजूद, क्या कनेक्शन लीजटाइमआउट अब कोर में लागू किया गया है? और यदि हां, तो इस मुद्दे को बंद क्यों नहीं किया जाता? मैं बिल्कुल मूल पोस्ट की तरह एक उदाहरण को कोड करने में सक्षम था जिसमें अभी कोई समस्या नहीं है। यह मेरे कनेक्शन DNS मुद्दों को हल करता है या नहीं, यह _seems_ ConnectionLeaseTimeout _is_ कोर में लागू किया गया है।

ServicePointMananager.ConnectionLeaseTimeout .NET कोर में लागू नहीं किया गया है। .NET कोर में इस संपत्ति का उपयोग करना एक नो-ऑप है। यह केवल .NET Framework में कार्यात्मक है। और डिफ़ॉल्ट रूप से, यह गुण .NET Framework में "बंद" पर सेट होता है।

मैं समझता हूं कि एक एकल-तत्काल इरादा है, लेकिन जब हम इसे Azure ऐप सेवाओं में उपयोग कर रहे हैं, तो हम एक बहुत ही मामूली लोड (ऊपर उल्लिखित, 250 अनुक्रमिक अनुरोध) के तहत HttpRequestExceptions को लगातार मार रहे हैं। जब तक कोई अन्य समाधान न हो, HttpClient को निपटाना वह समाधान है जिसे हमें इन सुसंगत अपवादों में चलने से बचने के लिए लागू करना था।

हम एक कस्टम एपीआई में HttpClient लपेटकर सॉकेट थकावट की समस्या का समाधान करने में सफल रहे हैं जो किसी एप्लिकेशन में प्रत्येक http अनुरोध को उसी HttpClient इंस्टेंस का पुन: उपयोग करने की अनुमति देता है (यह इससे कहीं अधिक करता है , जैसे RestSharp लेकिन यह भी लाभों में से एक है)। इसे प्राप्त करना lock{} पीछे है क्योंकि हर 60 मिनट में हम एक नया HttpClient बनाते हैं और इसके बजाय उसे वापस पास करते हैं। इसने हमें अपने वेब एप्लिकेशन से उच्च मात्रा में http अनुरोध करने की अनुमति दी है (हमारे पास भारी एकीकरण के कारण) जबकि अभी भी पुराने कनेक्शनों का पुन: उपयोग नहीं किया गया है जो बंद नहीं हुए हैं। हम इसे लगभग एक साल से सफलता के साथ कर रहे हैं (सॉकेट थकावट के मुद्दों को मारने के बाद)।

मुझे यकीन है कि इसमें अभी भी प्रदर्शन निहितार्थ हैं (विशेषकर सभी लॉकिंग के कारण) लेकिन यह सॉकेट थकावट के कारण मरने वाली हर चीज से बेहतर है।

@KallDrexx आपको 'वैश्विक' उदाहरण को लॉक करने की आवश्यकता क्यों है? Naively मैं इसे स्टैटिक में स्टोर करूंगा और इसे हर 60 मिनट में एक नए से बदल दूंगा। क्या यह काफी नहीं होगा?

HttpClient प्राप्त करने के लिए हमारा कोड है:

```सी#
var timeSinceCreated = DateTime.UtcNow - _lastCreatedAt;
अगर (timeSinceCreated.TotalSeconds > SecondsToRecreateClient)
{
ताला (पैडलॉक)
{
timeSinceCreated = DateTime.UtcNow - _lastCreatedAt;
अगर (timeSinceCreated.TotalSeconds > SecondsToRecreateClient)
{
_currentClient = नया HttpClient ();
_lastCreatedAt = दिनांक समय.UtcNow;
}
}
}

        return _currentClient;

```

तो मुझे लगता है कि ताला केवल प्रति मिनट एक बार होता है ताकि एकाधिक धागे एक साथ एक नया HttpApiClient बनाने की कोशिश नहीं कर रहे हों। मुझे लगा कि हम अधिक आक्रामक तरीके से लॉक कर रहे हैं।

मैं देखता हूं, तो यह एक सुविधाजनक कारण है।
वैकल्पिक रूप से आप या तो टाइमर-आधारित (async) अपडेट का उपयोग कर सकते हैं, या उनमें से कई को समानांतर (थ्रेड-असुरक्षित आलसी आरंभीकरण शैली) में बनाने की अनुमति दे सकते हैं, या विभिन्न सिंक्रनाइज़ेशन तंत्र का उपयोग कर सकते हैं और निर्माण समय के दौरान अन्य थ्रेड्स को ब्लॉक नहीं कर सकते हैं (वे पुराने का पुन: उपयोग कर सकता है)।

मैं देखता हूं, तो यह एक सुविधाजनक कारण है।

मुझे नहीं पता कि मैं इसे सुविधा के रूप में वर्गीकृत करूंगा या नहीं।

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

इसके अलावा, मुझे अभी भी लॉकिंग के कुछ उपाय की आवश्यकता होगी क्योंकि मुझे नहीं पता कि DateTime को अपडेट करना एक परमाणु ऑपरेशन है (मुझे संदेह नहीं है) और इसलिए कुछ धागे _lastCreatedAt मान को पढ़ सकते हैं अपडेट ऑपरेशन के बीच में।

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

उत्पादन में ऐसा करने के जोखिम के लिए बहुत अधिक अज्ञात और अतिरिक्त जटिलताएं हैं।

@KallDrexx

• ऐसा लगता है कि ReaderWriterLockSlim आपके उपयोग के लिए बेहतर होगा।
• यदि आप सही x64 चला रहे हैं तो DateTime असाइनमेंट परमाणु होना चाहिए (क्योंकि इसमें एक ulong फ़ील्ड है)। ध्यान दें कि यदि ऐसा नहीं है तो आपका वर्तमान कोड थ्रेड-सुरक्षित नहीं है, क्योंकि आप लॉक के बाहर DateTime मान देख रहे हैं।
• @karelz द्वारा सुझाए गए टाइमर-आधारित दृष्टिकोण को DateTime आवश्यकता नहीं होगी ... टाइमर बस HttpClient स्विच कर देगा। आपको अभी भी कुछ मेमोरी बैरियर के साथ HttpClient फ़ील्ड को घेरने की आवश्यकता होगी ( volatile , Interlocked.Exchange आदि)।

ऐसा लगता है कि ReaderWriterLockSlim आपके उपयोग के लिए बेहतर होगा।

नीट मैं उस वर्ग के बारे में नहीं जानता था! हालांकि, आपने इसका उल्लेख करते हुए मुझे SemaphoreSlim का उपयोग करने के बारे में भी सोचा, क्योंकि यह एसिंक/प्रतीक्षा अनुकूल है (जहां ऐसा लगता है कि ReaderWriterLockSlim नहीं है), जो संभावित थ्रेड विवाद में मदद कर सकता है जब एक नया HttpClient आवश्यक है। फिर फिर से ReaderWriterLockSlim संभावित DateTime गैर-परमाणु समस्या को बेहतर ढंग से संभालेगा जिसे आपने सही बताया है, इसलिए मुझे इसे कुछ विचार देना होगा, धन्यवाद!

@karelz द्वारा सुझाए गए टाइमर-आधारित दृष्टिकोण को

आह मैंने गलत तरीके से पढ़ा था कि उसका क्या मतलब है। यह समझ में आता है, हालांकि मुझे स्मृति बाधा तंत्र से इसे ठीक से करने के लिए और अधिक परिचित होने की आवश्यकता है।

धन्यवाद।

संपादित करें: बस जोड़ने के लिए, यह एक अच्छा कारण है कि मुझे लगता है कि इसे संभालने के लिए कुछ बनाया जाना चाहिए, इसलिए HttpClient प्रत्येक उपभोक्ता को इसे फिर से कार्यान्वित/जाने की आवश्यकता नहीं है।

मुझे आश्चर्य है कि क्या यह अभी भी .net कोर 2.0 में एक समस्या है? क्या हमें अभी भी DNS परिवर्तन के बारे में चिंता करने की ज़रूरत है?

मुझे आश्चर्य है कि क्या यह अभी भी .net कोर 2.0 में एक समस्या है? क्या हमें अभी भी DNS परिवर्तन के बारे में चिंता करने की ज़रूरत है?

मेरी समझ यह है कि यह डीएनएस के साथ कोई समस्या नहीं है, बस HttpClient मौजूदा कनेक्शन (सॉकेट थकावट को रोकने के लिए) का पुन: उपयोग करने का प्रयास करेगा, और इस प्रकार जब डीएनएस बदलता है तब भी आप पुराने से जुड़ रहे हैं सर्वर क्योंकि आप पिछले कनेक्शन पर जा रहे हैं।

@KallDrexx , तो इसका मतलब है कि इसमें अभी भी नीले-हरे रंग की तैनाती के मुद्दे होंगे?

@withinoneyear मेरी समझ से हाँ। यदि आप HttpClient बनाते हैं और इसे प्रोडक्शन ग्रीन के विरुद्ध उपयोग करते हैं, तो ब्लू में उत्पादन को स्वैप करें HttpClient में कनेक्शन बंद होने तक ग्रीन के लिए एक खुला कनेक्शन होगा।

मुझे पता है कि यह पुराना है, लेकिन मेरा मानना ​​है कि आपको समय अंतराल मापन के लिए DateTime.UtcNow का उपयोग नहीं करना चाहिए। Stopwatch.GetTimestamp जैसे मोनिटोनिक समय स्रोत का उपयोग करें। इस तरह आप ऑपरेटर या समय सिंक्रनाइज़ेशन द्वारा स्थानीय समय समायोजन के प्रति प्रतिरक्षित हैं। कुछ बग्गी चिपसेट थे जिन्होंने क्यूपीसी मूल्यों को वापस ले लिया, लेकिन मुझे विश्वास नहीं है कि उनमें से कई अब उपयोग में हैं।

var sp = ServicePointManager.FindServicePoint(नया उरी ("http://foo.bar/baz/123?a=ab"));
sp.ConnectionLeaseTimeout = 60*1000; // 1 मिनट

यह कोड कंस्ट्रक्टर में रखा गया है?

@whynotme8998 @lundcm मुझे नहीं लगता। यदि आप HttpClient सिंगलटन हैं और आप एकाधिक एनपॉइंट्स तक पहुंचते हैं तो कन्स्ट्रक्टर इसे रखने के लिए सही जगह नहीं होगा।
इस कार्यान्वयन की जाँच

क्या कोई मुझे यह समझने में मदद कर सकता है कि वास्तव में ConnectionLeaseTimeout का क्या अर्थ है?

अगर मेरे ऐप में मैं इसे 1 मिनट के लिए सेट करता हूं, तो क्या इसका मतलब है कि हर मिनट कनेक्शन लीज टाइमआउट हो जाएगा? मेरे बैक-एंड के साथ बात करने का वास्तव में क्या मतलब है?

मैं देख रहा हूं कि लोग बैक-एंड पर डीएनएस अपडेट करने की बात कर रहे हैं? एक मानक Azure वेब ऐप पर, मेरे ASP.NET बैक-एंड को प्रकाशित करने से DNS रीफ़्रेश हो जाएगा?

क्या 1 मिनट का टाइमआउट संभावित रूप से एक विंडो नहीं छोड़ेगा जहां DNS अपडेट हो गया है फिर भी टाइमआउट अभी तक नहीं हुआ है?

संपादित करें। इसे समझना .NET मानक 2.0 में काम नहीं करता है। कामकाज क्या है?

उस https://www.stevejgordon.co.uk/introduction-to-httpclientfactory-aspnetcore की प्रतीक्षा कर रहे हैं या इसके कुछ अंश स्वयं लागू कर रहे हैं।

कनेक्शन बदलने से लीज़टाइमआउट Xamarin पर .netstandard 2.0 के साथ काम नहीं करता है !!!

@paradisehuman मुझे लगता है कि आपका मतलब ServicePoint.ConnectionLeaseTimeout । AFAIK यह .NET कोर पर भी काम नहीं करता है। .NET Core 2.1 में हमने SocketsHttpHandler.PooledConnectionLifetime । साथ ही ASP.NET में नया HttpClientFactory दोनों का लाभ उठा सकता है और आपके लिए और भी बहुत कुछ करता है।
Mono/Xamarin का अपना नेटवर्किंग स्टैक कार्यान्वयन है (वे नेटवर्किंग के लिए CoreFX स्रोत कोड का उपभोग नहीं करते हैं) - इसलिए अधिक विवरण के साथ अपने रेपो पर बग दर्ज करना सबसे अच्छा होगा।

दुर्भाग्य से, आज .NET Core के साथ ऐसा करने का कोई तरीका नहीं है। या तो ServicePointManager को .NET कोर पर लाया जाना चाहिए या समान समकक्ष कार्यक्षमता को किसी अन्य तरीके से सक्षम किया जाना चाहिए।

@onovotny , .NET Core 2.1 में

@stephentoub अभी इसे देख रहे हैं, हाँ, मुझे लगता है कि PooledConnectionLifetime को इसे संबोधित करना चाहिए। अगर अभी भी किसी चीज की जरूरत है तो समुदाय एक और मुद्दा खोल सकता है।

@onovotny @karelz @stephentoub,

क्या आप सभी सहमत होंगे कि मूल सिंगलटन एचटीपी क्लाइंट/डीएनएस समस्या को हल करने के लिए यह एक सटीक सारांश है?

• .NET Framework 2.0+ में, ServicePoint.ConnectionLeaseTimeout ।

• .NET कोर 2.1 में, SocketsHttpHandler.PooledConnectionLifetime ।

• अन्य सभी प्लेटफार्मों/लक्ष्यों/संस्करणों के लिए, कोई विश्वसनीय समाधान/हैक/कार्य-आसपास नहीं है, इसलिए कोशिश करने से भी परेशान न हों।

जैसा कि मैं इस धागे और अन्य से चीजें सीखना जारी रखता हूं (जैसे ConnectionLeaseTimeout .NET मानक 2.0 में प्लेटफॉर्म पर विश्वसनीय रूप से काम नहीं कर रहा है), मैं एक तरह से पुस्तकालय से इसे हल करने की कोशिश कर रहे ड्राइंग बोर्ड पर वापस आ गया हूं जो अधिक से अधिक प्लेटफॉर्म/संस्करणों पर काम करता है। प्लेटफ़ॉर्म-सूँघना ठीक है। समय-समय पर HttpClient का निपटान/पुनर्निर्माण करना ठीक है, यदि यह प्रभावी है। मुझे पूरा यकीन है कि मैंने इसे अपने पहले प्रयास में गलत पाया, जो कि नियमित अंतराल पर होस्ट को केवल connection:close हेडर भेजना था। किसी भी सलाह के लिए अग्रिम धन्यवाद!

@tmenier अन्य सभी प्लेटफार्मों/लक्ष्यों/संस्करणों के लिए, कोई विश्वसनीय समाधान/हैक/कार्य-आसपास नहीं है, इसलिए कोशिश करने से भी परेशान न हों।

आप हमेशा नियमित आधार पर इंस्टेंस को रीसायकल कर सकते हैं (उदाहरण के लिए बस नया इंस्टेंस बनाएं और इसे स्टैटिक वेरिएबल पर सेट करें जो अन्य उपयोग करते हैं)।
यही HttpClientFactory करता है। आप इसके बजाय HttpClientFactory का उपयोग करना चुन सकते हैं।

@karelz धन्यवाद, मुझे लगता है कि यह मुझे आगे बढ़ने का रास्ता प्रदान करता है। शायद मुझे प्लेटफॉर्म को सूँघने और हर जगह रीसायकल के उदाहरणों को छोड़ देना चाहिए, या जहां उपलब्ध अन्य तरीकों का उपयोग करने की सलाह दी जाती है (ओवरहेड से बचने के लिए, आदि)?

मुश्किल बिट यह जान सकता है कि _जब_ पुनर्नवीनीकरण उदाहरणों का निपटान करना सुरक्षित है (मुझे समवर्ती/लंबित अनुरोधों के बारे में चिंता करने की ज़रूरत है), लेकिन मैं इस बात पर एक नज़र डाल सकता हूं कि HttpClientFactory निपटता है। एक बार फिर धन्यवाद।

@tmenier आप प्रत्येक HttpClient कॉल के उदाहरणों को रीसायकल नहीं करना चाहते हैं, क्योंकि इससे आपको टीसीपी सॉकेट थकावट हो जाएगी। पुनर्चक्रण को प्रबंधित करने की आवश्यकता है (समयबाह्य या HttpClient s के साथ एक पूल को बनाए रखना जिसे समाप्त किया जा सकता है।

@KallDrexx ठीक है, मैं सिर्फ _periodically_ एक सिंगलटन (या "छद्म" -सिंगलटन) को रीसाइक्लिंग करने के बारे में बात कर रहा हूं, जैसे कि हर कुछ मिनट। मुझे विश्वास है कि इसमें एक पूल का प्रबंधन और मृत उदाहरणों के किसी प्रकार का विलंबित निपटान शामिल होगा, एक बार यह निर्धारित हो जाने के बाद कि उनके पास कोई लंबित अनुरोध नहीं है।

आह क्षमा करें गलत समझा कि आप रीसायकल से क्या मतलब रखते हैं।

आपको पुराने को निपटाने की आवश्यकता नहीं होनी चाहिए। जीसी उन्हें इकट्ठा करने दें।
कोड समय-समय पर टाइमर के आधार पर नया "छद्म" -सिंगलटन सेट करने जितना आसान होना चाहिए। और अधिक कुछ नहीं।

मैंने पाया है कि उच्च प्रदर्शन परिदृश्यों में आपके http कनेक्शन से बाहर होने के कारण उनका निपटान नहीं करने से मंदी हो सकती है।

@tmenier .NET Core 2.1 में SocketsHttpHandler.PooledConnectionLifetime का उपयोग करने के बारे में, https://github.com/dotnet/wcf/blob/master/src/System.Private.ServiceModel/src/System/ में पूरी तरह से एनकैप्सुलेटेड में HttpClientHandler का निर्माण

@edavedian मैं डब्ल्यूसीएफ रेपो पर पूछने का सुझाव @mconnew @Lxiamail

अंतर्निहित स्टैक या तो WinHTTP या कर्ल का समाधान करता है जो उन्नत नियंत्रण नॉब्स को उजागर नहीं करता है

क्या नेट कोर में एक HTTP क्लाइंट है जो सॉकेट पर काम करता है?

क्या नेट कोर में एक HTTP क्लाइंट है जो सॉकेट पर काम करता है?

हां, सॉकेट एचटीपी हैंडलर, और 2.1 के रूप में यह डिफ़ॉल्ट है।

क्या HttpClient यूआरआई को कैश करता है, यह हिट करता है, वैसे ही रेस्ट क्लाइंट जो मुझे लगता है कि करता है? यदि ऐसा होता है, तो कृपया मुझे बताएं कि यह किस संस्करण (.NET Core 3.0/.NET Framework 3.0 आदि) पर इसका समर्थन करता है।

मैं देखता हूं कि कैशिंग केवल RestClient यदि प्रोजेक्ट एक नेट कोर 2.1+ ऐप है?

क्या एचटीपी क्लाइंट कैश यूआरआई 'यह हिट करता है, वैसे ही मुझे लगता है कि रेस्ट क्लाइंट क्या करता है?

HttpClient कोई कैशिंग नहीं करता है।

@SpiritBob यह स्पष्ट नहीं है कि आप किस प्रकार के कैशिंग का जिक्र कर रहे हैं। यह मुद्दा बंद है; यदि आप कृपया प्रश्नों के साथ एक नया मुद्दा खोलना चाहते हैं तो हम उत्तर खोजने में आपकी सहायता कर सकते हैं।

@scalablecory मेरा मानना ​​​​है कि डेविडश ने मेरे मन में जो जवाब दिया था, उसका जवाब दिया। धन्यवाद!

बस इस धागे को पढ़ना समाप्त कर दिया, और ऐसा लगता है कि कोई उपयोग मामला था जिसे संबोधित नहीं किया गया था।

का उपयोग करते समय HttpClientFactory , जिसके परिणामस्वरूप जाएगा HttpClient s अपने करीबी सम्बन्ध है और एक नया DNS लुकअप करते हैं जब वे प्राप्त एक HttpRequestException एक आंतरिक के साथ SocketException कि यह दर्शाता है होस्ट अब मान्य नहीं है और DNS संभावित रूप से बदल गया है (त्रुटि कोड 11001 - ऐसा कोई होस्ट ज्ञात नहीं है)?

यदि नहीं, तो DNS रिकॉर्ड्स पर TTL की समय-सीमा समाप्त होने से पहले HttpClient DNS लुकअप करने के लिए समाधान क्या है?

मैं वर्तमान में एक कस्टम HttpMessageHandler HttpClientFactory साथ AddHttpClient<T, U>().ConfigurePrimaryHttpMessageHandler(...) का उपयोग करके निर्भरता इंजेक्शन के माध्यम से कॉन्फ़िगर किया गया) और जब टीटीएल की समय सीमा समाप्त होने से पहले एक DNS रिकॉर्ड बदलता है, तो यह त्रुटिपूर्ण हो जाता है। विशेष रूप से, मैं इसे Azure ब्लॉब स्टोरेज पर अपलोड का एक गुच्छा करते समय देख रहा हूं।