HttpWebRequest.GetResponse()

Question

का उपयोग करते समय ThreadAbortException का कारण क्या हो सकता है मैं इस स्थिति के कारण दुःस्वप्न में रह रहा हूं, मेरे पास एक HttpWebRequest.GetResponse है जो मुझे थ्रेडएबॉर्ट अपवाद देता है, जिससे पूरे ऐप को नीचे जाना पड़ता है।

मैं इससे कैसे बच सकता हूं, या कम से कम इसे संभालने के लिए, थ्रेड.ResetAbort() का उपयोग ऐसे मामले में उपयोगी होगा?

यहाँ और अधिक व्याख्या करने के लिए एक मोटा कोड नमूना है:

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://someurl.com/"); 
HttpWebResponse resp = req.GetResponse(); 

अब अंतिम पंक्ति ऊपर ThreadAbortException फेंकता है, यह हो सकता है क्योंकि अनुरोध का समय समाप्त जो ठीक है, लेकिन मैं पाने के लिए नहीं करना चाहते हो सकता है मेरे ASP.NET 2.0 ऐप के अंदर एक थ्रेडअबोर्ट अपवाद क्योंकि यह इसे मारता है। ThreadAborException को कोशिश/पकड़ने के साथ पकड़ा नहीं जा सकता है, इसे संभालने का एकमात्र तरीका थ्रेड का उपयोग कर रहा है। रीसेट एबॉर्ट() जिसका अपना बुरा प्रभाव भी है, यह थ्रेड को जीवित रखेगा और भगवान केवल कितने समय तक जानता है।

Answer 1

जो आप कहते हैं उससे ऐसा लगता है कि आप एक आने वाले अनुरोध को एक एएसपी.NET एप्लिकेशन के प्रसंस्करण के भीतर बाहरी संसाधन के लिए आउटगोइंग वेबआरक्वेट बना रहे हैं।

• WebRequest.Timeout (डिफ़ॉल्ट 100000ms = 100s) निवर्तमान WebRequest के निष्पादन के लिए समय समाप्ति निर्दिष्ट करता है: वहाँ (कम से कम) दो समय समाप्ति है कि यहाँ प्रासंगिक हैं।यदि यह टाइमआउट समाप्त हो जाता है, तो आपको वेब अपवाद प्राप्त करना चाहिए - इसलिए यह आपकी समस्या नहीं है।

• आपके आने वाले अनुरोध को संसाधित करने वाले HttpRuntime में निष्पादन समय समाप्ति है: MSDN के अनुसार डिफ़ॉल्ट मान .NET 2.0 या बाद में, .NET 1.x के लिए 90s के लिए 110 है। जब यह टाइमआउट समाप्त हो जाता है, तो आपको थ्रेडएबॉर्ट अपवाद प्राप्त होगा। ऐसा लगता है कि यह हो रहा है।

नेट 1.x में, आप इस उम्मीद थी, क्योंकि डिफ़ॉल्ट HttpRuntime executionTimeout WebRequest.Timeout से कम है। .NET 2.0 में, यदि आप आउटगोइंग वेबआरक्वेट बनाने से पहले 10% पहले ही खर्च कर चुके हैं (उदाहरण के लिए यदि आपके पास एक ही आने वाले अनुरोध से एक से अधिक आउटगोइंग वेबआरक्वेट है) तो आप डिफ़ॉल्ट टाइमआउट के साथ इसकी अपेक्षा करेंगे।

मैं तुम्हें सुझाव है कि या तो:

• बाहर जाने वाले अनुरोधों के लिए WebRequest.Timeout कम करने, और WebException संभाल, या

• बाहर जाने वाले अनुरोधों वास्तव में इतना समय लग सकते हैं, तो वृद्धि httpRuntime MSDN में वर्णित निष्पादन समय समाप्ति।

Answer 2

मुझे प्रतिक्रिया का उपयोग करने में यह समस्या थी। कुछ कामकाज के लिए इस आलेख को देखें। http://support.microsoft.com/kb/312629

वेबएक्सप्शन और टिप्पणियों के लिए अनुभाग में इस एमएसडीएन दस्तावेज़ को भी देखें। http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse.aspx

यह अपवाद पकड़ा जा सकता है ... आप मुसीबत सही एक का पता लगाने कर रहे हैं, आप एक सामान्य अपवाद (system.Exception) को पकड़ने की कोशिश करनी चाहिए और वहाँ से स्टैक ट्रेस आप विशिष्ट प्रकार बताना चाहिए (HttpException, WebException, आदि) वास्तव में पकड़ने के लिए।

Answer 3

हमारे आवेदन ने उत्तरदायित्व ("url") कॉल के सभी समय बी/सी थ्रेडएबॉर्ट अपवाद को फेंक दिया। ऐप कभी बंद नहीं हुआ, सबसे अधिक संभावना बी/सी अपवाद कुछ बिंदु पर पकड़ा जा रहा था और सक्रिय रहा।

संयोग से, Response.Redirect ("url", false) प्रतिक्रिया को अपवाद के साथ समाप्त करने से रोक देगा। एंड्रयू का पोस्ट प्रतिक्रिया वर्ग के विभिन्न उपयोगों के लिए समान कार्यवाही से जुड़ा हुआ है।

Answer 4

मैंने एंड्रयू और "फॉरक्रिप्ससेक" द्वारा सूचीबद्ध दोनों समस्याओं को देखा है।

आपके थ्रेडएबॉर्टएक्सप्शन के लिए एक और संभावना सर्वर कोड पर पृष्ठ अनुरोध जीवनसाथी के बाहर चलाता है, जैसे कि एचटीपी मॉड्यूल और एचटीपी हैंडलर। मॉड्यूल या हैंडलर के भीतर फेंक दिया गया कोई भी अपवाद एएसपी.Net में डिफ़ॉल्ट अनचाहे अपवाद तंत्र पर नहीं जाता है, और धागे को मरने का कारण बन सकता है।

Reliability Best Practices

सुनिश्चित नहीं हैं कि अगर यह क्लाइंट कोड पर लागू होता है:

कुछ अपवाद भी है कि ASP.net या सामान्य रूप में CLR में आसानी से संभाला नहीं जा सकता की एक जोड़ी, इस लेख के अनुसार कर रहे हैं आपने अपने प्रश्न में सूचीबद्ध किया है, लेकिन यह संबंधित हो सकता है।

आशा है कि मदद करता है!