Ce ar putea provoca ThreadAbortException când utilizați HttpWebRequest.GetResponse ()

Din ceea ce spuneți, se pare că faceți o trimitere WebRequest către o resursă externă din cadrul procesării unei cereri de intrare către o aplicație ASP.NET. Există (cel puțin) două termene limită care sunt relevante aici:

• WebRequest.Timeout (implicit 100000ms = 100s) specifică intervalul de timp pentru executarea WebRequest-ului de ieșire. Dacă acest timp expiră, ar trebui să obțineți un WebException - deci nu este problema dvs.

• HttpRuntime care procesează cererea de intrare are un timeout de execuție: valoarea implicită în conformitate cu MSDN este 110s pentru .NET 2.0 sau mai târziu, 90 de ani pentru .NET 1.x. Când expiră acest timp, veți primi un ThreadAbortException. Se pare că se întâmplă acest lucru.

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).

V-aș sugera fie:

• Reduceți WebRequest.Timeout pentru cererile de ieșire și gestionați WebException sau

• Dacă cererile de ieșire pot dura cu adevărat atât de mult, apoi măriți timpul de execuție al execuției httpRuntime așa cum este descris în MSDN .

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

De asemenea, aruncați o privire la această documentație MSDN în secțiunea pentru WebExcepție și Observații. http://msdn.microsoft.com/ro- ne/biblioteca/system.net.httpwebrequest.getresponse.aspx

Această excepție poate fi prinsă ... Dacă întâmpinați dificultăți în detectarea celei potrivite, ar trebui să încercați să obțineți o excepție generală (system.Exception) și de acolo urmărirea stivei ar trebui să vă spună tipul specific (HttpException, WebException, etc) de fapt captura.

Aplicația noastră a aruncat tot timpul b/c lui ThreadAbortException Response.Redirect ("url") apeluri. Aplicația nu a fost închisă, cel mai probabil b/c excepția a fost prinsă la un moment dat și a rămas activă.

De altfel, Response.Redirect ("url", false) va împiedica încheierea răspunsului cu excepția. Postul lui Andrew trimite legături către soluții similare pentru diferite utilizări ale clasei de răspuns.

Am văzut ambele probleme enumerate de Andrew și "ForCripesSake".

O altă posibilitate pentru ThreadAbortException este orice cod care se execută în afara ciclului de viață al solicitării de pagină din partea serverului, cum ar fi HttpModules și HttpHandlers. Orice excepții aruncate într-un modul sau un handler nu merg la mecanismul implicit de excepție nestăvilit în ASP.Net și pot provoca moartea firului.

Există câteva excepții care nu pot fi gestionate cu ușurință în ASP.net sau CLR în general, în conformitate cu acest articol:

Cele mai bune practici de fiabilitate

Nu sunteți sigur dacă se aplică codului client pe care l-ați enumerat în întrebarea dvs., dar ar putea fi asociat.

Sper că vă ajută!