Azure ASP .net WebApp The request timed out

Question

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:

 [HttpGet]
    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:

[HttpGet]
    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
Host: longgetrequest.azurewebsites.net
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:

SCM_COMMAND_IDLE_TIMEOUT = 3600

WEBSITE_NODE_DEFAULT_VERSION = 4.2.3

Solution

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:
https://social.msdn.microsoft.com/Forums/en-US/17305ddc-07b2-436c-881b-286d1744c98f/503-errors-with-large-pdf-file?forum=windowsazurewebsitespreview

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?

Comments

[Pavel]

Thanks for you help. Great info under the link. Its written over there that "there is a 230 second (i.e. a little less than 4 mins) timeout for requests that are not sending any data back." But TCP Keep alive was made for sending data back, so session should not be marked as idled after 230s. Thats what was written in this article. I will mark your answer as correct one if I will get no other opinion in a week. Thanks

[evilSnobu]

While TCP keep-alives apply to Azure load balancers, they do not apply to App Service, since the 230-second timeout is a Layer 7 thing (HTTP), rather than transport layer (TCP, Layer 4).

[Josh Mouch]

Is this still true, or have they added anything in the last year that makes this configurable?

[evilSnobu]

Nope, still 230 seconds. If you need more it's no longer an interactive request. Should be 202 Accepted right away and defer work to background.

[pasul]

I was told that "A common practice to keep the connection active for a longer period is to use TCP Keep-alive. By keeping on-going network activity, the idle timeout value is never hit and the connection is maintained for a long period". I used SetTcpKeepAlive method in my client application and I see these TCP keep-alive packets going back and forth to my App Service in Azure, but it has no impact and an idle connection is still being closed after 230 seconds. Should this option help? Or it really is HTTP level on which the connection is closed, not TCP level?

[evilSnobu]

The TCP session is between your browser and App Service frontends. Frontends open a new connection to your web worker (your app) and ARR-proxy requests. Therefore your TCP keepalive does nothing but upset the frontends a little bit, if the frontend doesn't hear HTTP back from your web worker inside the 230-sec window, it's game over for that socket.