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