ما قد يسبب ThreadAbortException عند استخدام HttpWebRequest.GetResponse ()

أنا أعيش في كوابيس بسبب هذا الموقف ، ولدي HttpWebRequest.GetResponse الذي يبقى على إعطائي ThreadAbortException ، الذي يتسبب في التطبيق بأكمله إلى النزول.

كيف يمكنني تجنب ذلك ، أو على الأقل التعامل معها ، أن استخدام Thread.ResetAbort() يكون مفيدا في مثل هذه الحالة؟

لتوضيح المزيد هنا ، توجد عينة من التعليمات البرمجية الخام:

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

الآن السطر الأخير أعلاه يلقي ThreadAbortException ، قد يكون ذلك بسبب انتهاء المهلة الزمنية للطلب ، ولكن لا أريد الحصول على ThreadAbortException داخل تطبيق ASP.NET 2.0 لأنه يقتلها. لا يمكن اكتشاف ThreadAborException مع try/catch ، الطريقة الوحيدة للتعامل معه هي استخدام Thread.ResetAbort() الذي له تأثيراته السيئة أيضاً ، سيبقي الخيط على قيد الحياة والله وحده يعلم طول الوقت.

12
حاول التقاط System.Exception على السطر الثاني هناك ورؤية نوع العرض السابق.
وأضاف المؤلف StingyJack, مصدر
يمكنك التقاط ThreadAbortException ، عليك فقط التعامل معه بشكل صحيح. ResetAbort() هو الشيء الصحيح الذي ينبغي عمله عند الانتهاء. راجع msdn.microsoft.com/en-us/library/&hellip ؛ للمزيد.
وأضاف المؤلف Bob King, مصدر

4 إجابة

من ما تقوله يبدو أنك تقوم بإنشاء WebRequest الصادرة إلى مورد خارجي من داخل معالجة طلب وارد إلى تطبيق ASP.NET. هناك (على الأقل) مهلتان مناسبتان هنا:

  • يحدد WebRequest.Timeout (افتراضي 100000ms = 100s) المهلة لتنفيذ WebRequest الصادر. إذا انتهت صلاحية هذه المهلة ، فيجب أن تحصل على WebException - لذلك هذه ليست مشكلتك.

  • يمتلك HttpRuntime الذي يعالج طلبك الوارد مهلة تنفيذ: القيمة الافتراضية وفقًا لـ MSDN هو 110s لـ .NET 2.0 أو الأحدث ، 90s لـ .NET 1.x. عندما تنتهي صلاحية هذه المهلة ، ستحصل على ThreadAbortException. يبدو أن هذا هو ما يحدث.

In .NET 1.x, you'd expect this, because the default HttpRuntime executionTimeout is less than WebRequest.Timeout. In .NET 2.0, you'd expect this with the default timeouts if you have already spent >10s before making the outgoing WebRequest (e.g. if you have more than one outgoing WebRequest from within the same incoming request).

أود أن أقترح عليك إما:

  • تقليل WebRequest.Timeout للطلبات الصادرة ، والتعامل مع WebException ، أو

  • إذا كانت الطلبات الصادرة يمكن أن تستغرق وقتًا طويلاً ، فعليك زيادة مهلة تنفيذ httpRuntime كما هو موضح في MSDN .

    </لى>
12
وأضاف
كان httpRuntime.executionTimeout الجاني في السيناريو الخاص بي - شكرا!
وأضاف المؤلف RobSiklos, مصدر

I had this problem with using Response. Check out this article for some workarounds. http://support.microsoft.com/kb/312629

ألقِ نظرة أيضًا على وثائق MSDN هذه في القسم الخاص بـ WebException و Remarks. http://msdn.microsoft.com/en- لنا/مكتبة/system.net.httpwebrequest.getresponse.aspx

يمكن الاستثناء من هذا الاستثناء ... إذا كنت تواجه مشكلة في اكتشاف الخطأ الصحيح ، فيجب محاولة التقاط استثناء عام (system.Exception) ومن هناك يجب أن يخبرك تتبع المكدس النوع المحدد (HttpException ، WebException ، إلخ) إلى يمسك فعلا.

2
وأضاف

ألقى تطبيقنا ThreadAbortException في كل وقت ب/ج من Response.Redirect ("url") المكالمات. التطبيق لم يغلق ، على الأرجح ب/ج تم القبض على استثناء في مرحلة ما وظلت نشطة.

بالمناسبة ، سيمنع Response.Redirect ("url"، false) الاستجابة من إنهاء الاستثناء. تربط ارتباطات Andrew بالحلول المشابهة لاستخدامات مختلفة لفئة Response.

0
وأضاف
هذا دقيق (Response.Redirect (url) يستدعي Response.End الذي يلقي ThreadAbortException) ولكن ليس له علاقة بحالة OP.
وأضاف المؤلف Joe, مصدر

رأيت كلا من المشاكل المدرجة من قبل أندرو و "ForCripesSake".

احتمال آخر لـ ThreadAbortException هو أي رمز يتم تشغيله خارج دورة حياة طلب الصفحة على جانب الخادم ، مثل HttpModules و HttpHandlers. أي استثناءات القيت داخل وحدة نمطية أو معالج لا تذهب إلى آلية الاستثناء الافتراضية غير المعالجة في ASP.Net ، ويمكن أن تتسبب في موته.

هناك بعض الاستثناءات التي لا يمكن معالجتها بسهولة في ASP.net أو CLR بشكل عام ، وفقًا لهذه المقالة:

أفضل ممارسات الموثوقية

لست متأكدًا مما إذا كان ينطبق على رمز العميل الذي أدرجته في سؤالك ، ولكن قد يكون مرتبطًا.

امل ان يساعد!

0
وأضاف