quarta-feira, 14 de junho de 2017

ASP.NET: ThreadAbortException

Olá. Vamos ao caso de hoje: em um projeto que trabalhei de um site em ASP.NET, existe uma página que é basicamente um relatório, contendo uns resumos dos dados de um mês, colocado em um monte de gráficos. Então, em um desses relatórios em que se tinha acumulado muito dados, começou a dar um erro estranho, um “Time Out [Internal Error]”. A princípio achei que era o banco de dados, que deveria ter muitos dados e deu Time Out, mas quando executei, tinha apenas um pouco menos de mil registros, logo não poderia acontecer.



Visualizando o log, encontrei vários "System.Threading.ThreadAbortException" e finalizando com "System.Web.HttpException: Request timed out". Pesquisando sobre o tal ThreadAbortException, encontro basicamente o seguinte motivo: uma chamada para o método Response.Redirect, que cria a exceção e tal.  Continuando com os sintomas, o problema estava ocorrendo apenas na produção, quando tentava debugar, na esperança de que o depurador ajudasse a identificar a causa, nunca ocorria, e o relatório era gerado normalmente.Então, conclui que deve haver alguma configuração que fazia com que os request tivesse prazo de validade, e que uma vez que atingisse o prazo, abortava a execução. Com uma boa pesquisa e voilà! Existe uma configuração que é feita no Web.config no atributo <httpRutime> que é o “executionTimeout”. Quando a página faz uma requisição, o tempo de processamento estourava o valor padrão, que é de 110 segundos. Para isso, apenas modifiquei o web.config da seguinte maneira:
<httpRuntime executionTimeout=”300”>


e o problema acabou.

Ou seja, o problema foi causado pela demora do processamento dos dados, com isso, o tempo da execução estourava os 110 segundos, tempo que o ASP.NET espera antes de abortar automaticamente a execução. Aumentando esse prazo permitiu dar tempo ao processo finalizar seus procedimentos e retornar. Ah! Lembra o fato de que nunca ocorria esse problema quando eu tentei debugar? O fato é que no depurador, o ASP.NET ignora esse tempo, uma vez que se o programador estiver usando breakpoints e tal, esse tempo pode ser ultrapassado facilmente. 

Nenhum comentário:

Postar um comentário