हमारे पास डब्ल्यूसीएफ सेवाओं का एक समूह है जो विभिन्न बाइंडिंग, बंदरगाहों, अधिकतम आकार इत्यादि का उपयोग करते हुए लगभग हर समय काम करता है। डब्ल्यूसीएफ के बारे में सुपर-निराशाजनक बात यह है कि जब यह (शायद ही कभी) विफल हो जाती है, हम यह पता लगाने के लिए शक्तिहीन हैं कि यह क्यों विफल हुआ।डब्ल्यूसीएफ टाइमआउट एक दुःस्वप्न
System.ServiceModel.CommunicationException: सॉकेट कनेक्शन निरस्त किया गया था कभी-कभी आप संदेश है कि इस तरह दिखता है मिल जाएगा। यह आपके संदेश को संसाधित करने में त्रुटि या दूरस्थ समय होस्ट, या अंतर्निहित नेटवर्क संसाधन समस्या से अधिक होने के कारण प्राप्त हो सकता है। स्थानीय सॉकेट टाइमआउट '01: 00: 00 'था। ---> System.IO.IOException: परिवहन कनेक्शन से डेटा पढ़ने में असमर्थ: मौजूदा कनेक्शन जबरन दूरस्थ होस्ट द्वारा बंद किया गया था।
समस्या यह है कि स्थानीय सॉकेट टाइमआउट जो आपको दे रहा है केवल सुविधाजनक होने का प्रयास है। यह समस्या का कारण हो सकता है या नहीं भी हो सकता है। लेकिन ठीक है, कभी-कभी नेटवर्क में समस्याएं होती हैं। कोई बड़ी बात नहीं। हम पुनः प्रयास कर सकते हैं या कुछ। लेकिन यहां बड़ी समस्या है। आपको यह बताने में नाकाम रहने के शीर्ष पर कि कौन सा समय समाप्ति (यदि कोई है) विफलता के परिणामस्वरूप ("आपका सर्वर-साइड टाइमआउट पार हो गया था," या कुछ उपयोगी होगा), डब्ल्यूसीएफ के पास दो प्रकार के टाइमआउट हैं।
टाइमआउट प्रकार # 1) टाइमआउट, कि, अगर वृद्धि हुई है, आपके ऑपरेशन की सफलता की संभावना बढ़ जाएगी। तो, प्रासंगिक समय समाप्ति एक घंटा है, आप एक बड़ी फाइल अपलोड कर रहे हैं जिसमें एक घंटे और बीस मिनट लगेंगे। यह विफल रहा। आप टाइमआउट बढ़ाते हैं, यह सफल होता है। मुझे इस प्रकार के टाइमआउट के साथ कोई समस्या नहीं है।
टाइमआउट प्रकार # 2) टाइमआउट जो केवल परिभाषित करता है कि कब तक आप सेवा के लिए वास्तव में असफल और आपको एक त्रुटि दे, लेकिन इस समय समाप्ति के मान को संशोधित करने की संभावना को प्रभावित नहीं होती करने के लिए इंतजार करना पड़ता है सफलता। असल में, सेवा अनुरोध के पहले दूसरे के दौरान कुछ होता है जो चीज़ों को बेकार करता है। यह कभी ठीक नहीं होगा। डब्ल्यूसीएफ आपके लिए नेटवर्क कनेक्शन को जादुई रूप से पुनः प्रयास नहीं करता है। ठीक है, कभी-कभी नेटवर्क कनेक्शन स्थापित करना अच्छा नहीं होता है। लेकिन, यदि आपका टाइमआउट 2 घंटे है, तो आपको 2 घंटे पूरे इंतजार करना होगा, इससे पहले कि यह अंततः यह स्वीकार न करे कि यह काम नहीं करता है और आपको त्रुटि देता है।
लेकिन दोनों मामलों में आप जो त्रुटि देखते हैं वह वही दिखता है। टाइमआउट टाइप # 2 के साथ, ऐसा लगता है कि आप एक टाइमआउट में चल रहे हैं। लेकिन, आप अपने सभी टाइमआउट को 4 साल तक बढ़ा सकते हैं, और यह सब कुछ करने में त्रुटि संदेश प्राप्त करने में 4 साल लगते हैं। मुझे पता है कि टाइप # 2 मौजूद है क्योंकि मैं एक ऑपरेशन कर सकता हूं जिसे सफल होने पर एक मिनट से भी कम समय में पूरा करने के लिए जाना जाता है, और इसमें असफल होने में 2 घंटे लगते हैं। लेकिन, अगर मैं इसे मारता हूं और पुनः प्रयास करता हूं, तो यह जल्दी से सफल होता है। (यदि आप सोच रहे हैं कि एक ऑपरेशन पर 2 घंटे का टाइमआउट क्यों हो सकता है जो एक मिनट से भी कम समय लेता है, तो कई बार मैं एक बड़ी फाइल के साथ ऑपरेशन चलाता हूं और इसमें एक घंटे लग सकते हैं।)
तो, टाइप # 2 के साथ समस्या का मुकाबला करने के लिए, आप चाहते हैं कि आपका टाइमआउट वास्तव में जल्दी हो ताकि आप तुरंत किसी समस्या के बारे में जान सकें। फिर आप पुनः प्रयास कर सकते हैं। लेकिन दुर्बल समस्या यह है कि क्योंकि मुझे नहीं पता कि कौन से टाइमआउट विफलता का कारण हैं, मुझे नहीं पता कि टाइमआउट किस प्रकार टाइप # 1 हैं और कौन से प्रकार # 2 हैं। एक टाइमआउट हो सकता है (मान लें कि क्लाइंट-साइड टाइमआउट भेजें) जो कुछ मामलों में टाइप # 1 जैसा काम करता है और दूसरों में टाइप # 2 टाइप करता है। मुझे नहीं पता, और मेरे पास खोजने का कोई तरीका नहीं है।
क्या कोई जानता है कि टाइप # 2 टाइमआउट को कैसे ट्रैक किया जाए, इसलिए मैं उन्हें वास्तविक (संक्षिप्त: टाइप # 1) टाइमआउट को कम किए बिना कम मूल्यों पर सेट कर सकता हूं और सफलता का मौका कम कर सकता हूं?
धन्यवाद। प्रकार # एंड्रयू एंडरसन की टिप्पणी के जवाब में 2 समय समाप्ति की
स्पष्टीकरण:
मेरे विश्वास है कि कुछ ग्राहक के अनुरोध और कोड सर्वर पर अमल करने के लिए शुरू करने के बीच गलत हो जाता है। सभी मामलों में जहां हमारे पास सर्वर कोड आंशिक प्रगति दर्शाता है, यह पूरी चीज को खत्म किए बिना कुछ ऑपरेशन कभी खत्म नहीं हुआ है। इसलिए, सर्वर कोड निष्पादित नहीं होता है, और इसे निष्पादित करने में कितना समय लगेगा अप्रासंगिक है (इसके अलावा यह हमारे टाइमआउट मान को पहले स्थान पर सेट करने के लिए इसे लागू करने के लिए प्रभावित करता है)।
स्पष्टीकरण टाइप 2 टाइमआउट पर अनुरोध किया गया है: क्या असफल रहा है? सेवा-साइड कोड, या क्लाइंट से कनेक्शन का अनुरोध करने के बीच कुछ और वास्तव में सेवा पक्ष पर आपके विधि कॉल को निष्पादित करना प्रारंभ कर रहा है? –
क्या आप उन "टाइप 2" -मेस्टरियंस और सटीक बाध्यकारी कॉन्फ़िगरेशन के चरणबद्ध विवरण से एक सरल कदम दे सकते हैं जिसका आप उल्लेख कर रहे हैं? – Alex
यह समस्या प्रोजेक्ट प्रबंधन (क्लाइंट्स के रूप में) और डेवलपर्स (सेवाओं के रूप में) के बीच समान है। किसी भी समय एक टाइमआउट से अधिक है, परियोजना प्रबंधन जानना चाहता है कि यह एक प्रकार 1 या टाइप 2 है। हालांकि, डेवलपर्स को पता नहीं है (वे अभी तक समाप्त नहीं हुए हैं), और इसलिए सलाह नहीं दे सकते हैं। –