Pavel Pavel - 1 year ago 990
C# Question

Azure ASP .net WebApp The request timed out

I have deployed an ASP .net MVC web app to Azure App service.

I do a GET request from my site to some controller method which gets data from DB(DbContext). Sometimes the process of getting data from DB may take more than 4 minutes. That means that my request has no action more than 4 minutes. After that Azure kills the connection - I get message:

500 - The request timed out.

The web server failed
to respond within the specified time.

This is a method example:

public async Task<JsonResult> LongGet(string testString)
var task = Task.Delay(360000);
await task;
return Json("Woke", JsonRequestBehavior.AllowGet);

I have seen a lot of questions like this, but I got no answer:

Not working 1
Cant give other link - reputation is too low.

I have read this article - its about Azure Load Balancer which is not available for webapps, but its written that common way of handling my problem in Azure webapp is using TCP Keep-alive. So I changed my method:

public async Task<JsonResult> LongPost(string testString)
ServicePointManager.SetTcpKeepAlive(true, 1000, 5000);
ServicePointManager.MaxServicePointIdleTime = 400000;
ServicePointManager.FindServicePoint(Request.Url).MaxIdleTime = 4000000;
var task = Task.Delay(360000);
await task;
return Json("Woke", JsonRequestBehavior.AllowGet);

But still get same error.
I am using simple GET request like

GET /Home/LongPost?testString="abc" HTTP/1.1
Cache-Control: no-cache
Postman-Token: bde0d996-8cf3-2b3f-20cd-d704016b29c6

So I am looking for the answer what am I doing wrong and how to increase request timeout time in Azure Web app. Any help is appreciated.

Azure setting on portal:

Web sockets - On

Always On - On

App settings:



Answer Source

230 seconds. That's it. That's the in-flight request timeout in Azure App Service. It's hardcoded in the platform so TCP keep-alives or not you're still bound by it.

Source -- see David Ebbo's answer here:

There is a 230 second (i.e. a little less than 4 mins) timeout for requests that are not sending any data back. After that, the client gets the 500 you saw, even though in reality the request is allowed to continue server side.

Without knowing more about your application it's difficult to suggest a different approach. However what's clear is that you do need a different approach --

Maybe return a 202 Accepted instead with a Location header to poll for the result later?

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download