O que pode causar ThreadAbortException ao usar HttpWebRequest.GetResponse ()

Eu estou vivendo em pesadelos por causa desta situação, eu tenho um HttpWebRequest.GetResponse que continua me dando um ThreadAbortException, que faz com que o aplicativo inteiro vá para baixo.

Como posso evitar isso, ou pelo menos lidar com isso, seria útil usar Thread.ResetAbort() em tal caso?

Para explicar mais, aqui está um exemplo de código aproximado:

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

agora a última linha acima lança o ThreadAbortException, pode ser porque a solicitação expirou, o que é bom, mas eu não quero obter um ThreadAbortException dentro do meu aplicativo ASP.NET 2.0 porque ele o mata. O ThreadAborException não pode ser capturado com try/catch, a única maneira de manipulá-lo é usando Thread.ResetAbort (), que também tem seus próprios efeitos ruins, manterá o thread ativo e só Deus sabe por quanto tempo.

12
Tente pegar um System.Exception na segunda linha e veja que tipo de ex é lançado.
adicionado o autor StingyJack, fonte
Você pode pegar ThreadAbortException, você apenas tem que lidar com isso corretamente. ResetAbort() é a coisa certa a fazer quando estiver pronto. Consulte msdn.microsoft.com/pt-br/library/&hellip ; para mais.
adicionado o autor Bob King, fonte

4 Respostas

Do que você diz, parece que você está fazendo um WebRequest de saída para um recurso externo de dentro do processamento de uma solicitação de entrada para um aplicativo ASP.NET. Existem (pelo menos) dois tempos limite relevantes aqui:

  • WebRequest.Timeout (padrão 100000ms = 100s) especifica o tempo limite para execução do WebRequest de saída. Se esse tempo limite expirar, você deverá obter uma WebException, portanto, isso não é problema seu.

  • O HttpRuntime que está processando sua solicitação recebida tem um tempo limite de execução: o valor padrão de acordo com MSDN é o 110s para .NET 2.0 ou posterior, 90s para .NET 1.x. Quando esse tempo limite expirar, você receberá um ThreadAbortException. Parece que isso é o que está acontecendo.

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

Eu sugiro que você também:

  • Reduza o WebRequest.Timeout para solicitações de saída e manipule o WebException ou

  • Se as solicitações de saída puderem realmente levar tanto tempo, aumente o tempo limite de execução do httpRuntime, conforme descrito em MSDN .

12
adicionado
httpRuntime.executionTimeout foi o culpado no meu cenário - obrigado!
adicionado o autor RobSiklos, fonte

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

Também dê uma olhada nesta documentação do MSDN na seção de WebException e Remarks. http://msdn.microsoft.com/pt-BR nós/library/system.net.httpwebrequest.getresponse.aspx

Esta exceção pode ser detectada ... Se você está tendo problemas para detectar o caminho certo, você deve tentar capturar uma exceção geral (system.Exception) e a partir daí o rastreamento de pilha deve informar o tipo específico (HttpException, WebException, etc) para realmente pegar.

2
adicionado

Nosso aplicativo jogou o tempo todo de ThreadAbortException b/c de Response.Redirect ("url") chamadas. O aplicativo nunca fechou, provavelmente b/c a exceção estava sendo capturada em algum ponto e permaneceu ativa.

Aliás, Response.Redirect ("url", false) impedirá que a resposta termine com a exceção. O post de Andrew relaciona-se com soluções alternativas semelhantes para diferentes usos da classe Response.

0
adicionado
Isso é preciso (Response.Redirect (url) chama Response.End, que lança um ThreadAbortException), mas não é relevante para a situação do OP.
adicionado o autor Joe, fonte

Eu vi os dois problemas listados por Andrew e "ForCripesSake".

Outra possibilidade para o seu ThreadAbortException é qualquer código executado fora do ciclo de vida da solicitação de página no lado do servidor, como HttpModules e HttpHandlers. Quaisquer exceções lançadas em um módulo ou manipulador não vão para o mecanismo de exceção não tratada padrão no ASP.Net e podem fazer com que o segmento morra.

Há algumas exceções que não podem ser tratadas facilmente no ASP.net ou no CLR em geral, de acordo com este artigo:

Práticas recomendadas de confiabilidade

Não tenho certeza se isso se aplica ao código do cliente listado na sua pergunta, mas pode estar relacionado.

Espero que ajude!

0
adicionado