वेब सेवा का उपभोग करने में त्रुटि: मौजूदा कनेक्शन को जबरन बंद कर दिया गया था

Question

मेरे पास सी # में एक विनफॉर्म एप्लिकेशन है जो विंडोज 2008 आईआईएस कोल्डफ्यूजन सर्वर से वेब सेवाओं का उपभोग करता है। सभी वेब सेवा कॉल सफल होते हैं लेकिन एक, जो निम्न त्रुटि के साथ लगभग 50% समय में विफल रहता है:

सिस्टम। इन्वालिडऑपरेशन अपवाद उपयोगकर्ता कोड संदेश द्वारा अनचाहे किया गया था = XML दस्तावेज़ (1254, 7) में कोई त्रुटि है।

की एक आंतरिक अपवाद के साथ

:

InnerException: System.IO.IOException संदेश = परिवहन कनेक्शन से डेटा पढ़ने में असमर्थ: एक मौजूदा कनेक्शन बलपूर्वक दूरस्थ होस्ट द्वारा बंद कर दिया गया था।

मैंने अपने आईआईएस लॉग की जांच की और मुझे 503 त्रुटि (सेवा अनुपलब्ध) और 64 का आईआईएस कोड मिला (निर्दिष्ट नेटवर्क अब उपलब्ध नहीं है)। कोई भी सुझाव बढ़िया होंगे।

मैं सोप यूआई में अपने वेब सेवा चलाने के लिए और मैं निम्नलिखित त्रुटि मिलती है:

javax.net.ssl.SSLException: कनेक्शन किया गया है बंद: javax.net.ssl.SSLException: java.net.SocketException: कनेक्शन रीसेट

यह कोड एक कंपनी में ठीक काम करता है लेकिन यह त्रुटि इस कंपनी के लिए लगभग हर बार पॉप अप करती है जिसके साथ मैं वर्तमान में काम कर रहा हूं।

Answer 1

मुझे इसी तरह की त्रुटि मिली और एक्सएमएल क्रमबद्धता में अपवाद था। अधिकतर यदि xmlserializer कुछ संपत्ति को पढ़ने की कोशिश करता है और कुछ डेटाबेस कनेक्शन पहले से बंद होने या किसी भी संसाधन उपलब्ध नहीं होने के कारण विधि प्राप्त हो जाती है।

क्या आपने global.asax के अंदर त्रुटि ईवेंट में अपवाद लॉग करने का प्रयास किया है?

कभी-कभी अगर global.asax त्रुटि ईवेंट नहीं बढ़ाता है, तो प्रतिक्रिया फ़िल्टर के माध्यम से त्रुटि लॉग करने का एकमात्र तरीका। आप web.config में कस्टम प्रतिक्रिया फ़िल्टर जोड़ सकते हैं, जिसमें आप यह विश्लेषण करने में सक्षम होंगे कि एक्सएमएल सही तरीके से क्रमबद्ध किया गया था और यह असफल हो सकता है।

http://msdn.microsoft.com/en-us/library/aa479332.aspx

http://www.raboof.com/projects/elmah/

Answer 2

आप एक WCF ग्राहक का उपयोग कर रहे हैं, तो सेवा से कनेक्ट निम्नलिखित config के साथ अपने क्लाइंट अनुप्रयोग में सेवा का पता लगाने लॉगिंग सक्षम करने:

<system.diagnostics> 
    <trace autoflush="true" /> 
    <sources> 
     <source name="System.ServiceModel" 
         switchValue="Error" 
         propagateActivity="true"> 
      <listeners> 
       <add name="sdt" 
         type="System.Diagnostics.XmlWriterTraceListener" 
         initializeData= "ErrorTrace.svclog" 
         /> 
      </listeners> 
     </source> 
    </sources> 
</system.diagnostics> 

डाउनलोड खिड़कियां sdk और आपके पास इन लॉग फ़ाइलों के लिए एक अच्छा ट्रेस व्यूअर है। यह आपको डब्ल्यूसीएफ संचार में त्रुटियों के निचले हिस्से तक पहुंचने में मदद करता है।

Answer 3

क्रॉस प्लेटफ़ॉर्म संचार का उपयोग करना कभी-कभी ऐसा होता है (एक बार मेरे कोड पर हुआ) कि अपवाद फेंक दिया गया है कि अंदर क्या हो रहा है इसका असली विवरण नहीं है।

इस अपवाद का एक कारण यह है कि आपका प्रतिक्रिया समय वेब सेवा विधि को पूरा करने के लिए आवश्यक समय से थोड़ा कम है। तो अपने app.config में टाइमआउट बढ़ाने की कोशिश करें।

यदि यह काम नहीं करता है तो आपके मामले में दो संभावित समस्याएं हो सकती हैं।

1. यदि SSL का उपयोग किया जाता है तो SSL प्रमाणपत्र वैधता में समस्या है।
2. XML में उपयोग किए गए कुछ अमान्य वर्ण हैं उदाहरण के लिए आपका प्लेटफ़ॉर्म यूनिकोड वर्णों का समर्थन नहीं करता है और कुछ गैर-समर्थित वर्ण XML में उपयोग किए जाते हैं।

लेकिन मुझे आशा है कि टाइमआउट को बढ़ाने से यह ठीक हो जाएगा।

Answer 4

इंटरमीडिएट "रिमोट होस्ट द्वारा एक मौजूदा कनेक्शन जबरन बंद कर दिया गया था" केवल एक गंतव्य से मुझे नेटवर्किंग समस्या की तरह लगता है।

उस सर्वर से लॉग प्राप्त करने का प्रयास करें जिसे आप एक्सेस करने का प्रयास करते हैं और दोनों स्थानों के शामिल फ़ायरवॉल से। आप आगे निदान करने के लिए Fiddler या NetMon/वायरशर्क/इथरियल चला सकते हैं।

Answer 5

किसी भी परिस्थिति के लिए कनेक्शन बंद होता है। सुनिश्चित करें कि सर्वर और क्लाइंट पर टाइमआउट प्रचुर मात्रा में है, सुनिश्चित करें कि आपके द्वारा लौटाए जा रहे डेटा में कोई रिकर्सन नहीं है। वृत्तीय संदर्भ। इस मामले में सीरियलाइजेशन महत्वपूर्ण है क्योंकि लौटाए जाने पर चीज को क्रमबद्ध किया जा रहा है।

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

पहले त्रुटि एक गरीब अपवाद के साथ वेब सेवा की ओर हो रहा है फेंक दिया जा रहा है, शायद कुछ अमान्य डेटा सेवा में गुजर किया जा रहा है:

Answer 6

यह अंधेरे में एक शॉट हो सकता है लेकिन यहां हो सकता है मेरी सिद्धांत है? यह एक्सएमएल के विकृत होने के बारे में त्रुटि वापस कर सकता है। मैं यह देखने के लिए कई परीक्षण मामले करूंगा कि सेवा में कौन सा डेटा पारित किया जा रहा है और इस मुद्दे का कारण क्या है।

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

Answer 7

अपने वर्तमान कंपनी के साथ अपने पिछले कंपनी में मौजूदा प्रोटोकॉल की जांच और उनकी तुलना करने की कोशिश, मेरा मतलब है टीसीपी/आईपी, ...

Answer 8

मैं हाल ही में एक ऐसी ही संदेश है जब एक WCF-वेब सेवा लेने वाली मिला है। मेरे मामले में यह सर्वर पक्ष पर कॉन्फ़िगरेशन त्रुटि होने के लिए चालू हो गया। हो सकता है कि कुछ सर्वर पर कॉन्फ़िगर किया गया हो, जहां यह आपके साथ होता है? मेरी समस्या यह थी कि डिफ़ॉल्ट अधिकतम संदेश आकार सर्वर पर बहुत छोटे होने के लिए कॉन्फ़िगर किया गया था और इसके परिणामस्वरूप एक ही मजबूर कनेक्शन बंद हो गया। डीओएस हमलों से बचने के लिए एक डिफ़ॉल्ट अधिकतम संदेश आकार है ...

Answer 9

आईआईएस में ऐप पूल रीसाइक्लिंग कॉन्फ़िगरेशन की जांच करें। मैंने यह त्रुटि देखी है, उदाहरण के लिए, जब "निजी मेमोरी सीमा" एक मान पर सेट की जाती है (100 एमबी कहें) और फिर w3wp प्रक्रिया इस सीमा से अधिक हो जाती है जिससे ऐप पूल को पुनर्नवीनीकरण किया जा सकता है।

यह आमतौर पर कोई समस्या नहीं है क्योंकि किसी भी मौजूदा कनेक्शन को पूरा करने के लिए समय दिया जाता है और नए कनेक्शन को नए स्पून-अप ऐप पूल द्वारा संसाधित किया जाएगा।

यदि सभी कनेक्शन शटडाउन समय सीमा के भीतर बंद नहीं होते हैं (आमतौर पर 9 0 सेकेंड) तो वे आईआईएस द्वारा मारे जाते हैं और ग्राहक "मौजूदा कनेक्शन जबरन बंद कर दिया गया" त्रुटि उठा सकता है।

Answer 10

मुझे यकीन नहीं है कि यह ओपी की विशिष्ट स्थिति पर लागू है, लेकिन यह आजकल यहां आने वाले अन्य लोगों की सहायता कर सकता है। इस अपवाद के लिए एक संभावित कारण में बेमेल सुरक्षा प्रोटोकॉल शामिल हैं। यदि आप जिस सर्वर को कॉल कर रहे हैं उसे टीएलएस 1.2 की आवश्यकता है और आप ASP.net (< = संस्करण 4.0) के पुराने संस्करण का उपयोग कर रहे हैं, तो आप अपनी कॉल करने के लिए पुराने सुरक्षा प्रोटोकॉल का उपयोग करेंगे जब तक आप इसे बदल नहीं देते। आप एएसपीनेट को टीएलएस 1.2 (नीचे दिखाया गया) का उपयोग करने के लिए मजबूर कर सकते हैं। यह एप्लिकेशन में कहीं भी किया जा सकता है, लेकिन मैंने इसे उस लाइन से पहले रखा है जो वेब सेवा को टीएलएस 1.2:

using System.Net; 

... 

//Enable TLS 1.2 
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; 

// Call the Web Service that requires TLS 1.2