Join Log in
Score:1
bbergvt avatar Server

ASP.net IIS requests not timing out after executionTimeout Value

in flag
bbergvt

We have set system.web/httpRuntime executionTimeout = 60s for our .net 4.8 application hosted on server 2019 IIS 10. From time to time we see varied requests exceeding this timeout by a large margin, sometimes requests show up as running for hours. What would be cases where this timeout would not be honored? IIS settings

Handful of long running requests

159
0 + 0
iis
Score:1
Kyle Kilpatrick avatar Server
mr flag
Kyle Kilpatrick

I had this same problem and had a very hard time tracking the answer down, and the short answer is "executionTimeout handling isn't implemented in the latest versions of pre-Core ASP.NET MVC" (and this is also true for any non-MVC ASP.NET app that uses asynchronous request handling). You have to make your own request timeout logic in your application. The same is true of IIS-hosted ASP.NET Core applications if they are using the in-process session state; out-of-process session state honors the executionTimeout setting in ASP.NET Core applications (but turning off in-process session state in pre-Core ASP.NET doesn't solve it--I tried).

Longer Explanation

IIS execution timeouts stopped working in (pre-Core) ASP.NET after the internal HTTP operations became asynchronous. When HTTP operations were synchronous, the runtime just watched to see how long a request's thread lived and then killed it if it took too long, and that worked because one thread was always tied to one request. But once the framework evolved to where the HTTP operations became asynchronous, that timeout model no longer worked because one thread ends up handling multiple requests, so you can't just safely kill a thread after such and such a time.

Thus, if you really want inbound requests to time out on pre-Core ASP.NET, you have to implement your own request timeout logic for that in your application. ASP.NET Core on the other hand seems like it might actually still work with the httpRuntime executionTimeout setting (though I've not tested it myself), but even then it will only work in an out-of-process session state context; an in-process session state context for an IIS-hosted ASP.NET Core application will ignore the timeout.

Red Herrings

Many answers on the web say "turn off system.web compile debug mode in the web.config". While ASP.NET's debug mode does indeed intentionally stop timeouts from being observed, and while turning the flag to false used to solve the problem, it will not anymore.

Some answers from 2011 also claimed that the issue would be solved in MVC 4, but it never was.

Sources

Pre-Core ASP.NET

https://social.msdn.microsoft.com/Forums/en-US/4c50c754-d667-4fef-9975-6fe6a8da62e3/webconfig-executiontimeout-not-working-in-aspnet-mvc?forum=aspmvc

https://social.msdn.microsoft.com/Forums/en-US/e1141be5-ef9b-4131-8766-315e495e1b4e

ASP.NET Core

https://github.com/dotnet/aspnetcore/issues/23160

+ 1
cn flag
Greg Askew
Interesting information, but I can see how this is an edge case. Many organizations have three things in the pipeline that would tear down idle connections before this scenario presented. Or prevent the situation entirely given it does not occur with Session State.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.