Timeouts with Long Running ASP.NET MVC Core Controller Httppost Method

Timeouts with long running ASP.NET MVC Core Controller HTTPPost Method

But in .Net Core 2.0 there is no web.config file in project. It generate automatically.

I solved the problem by adding .UseKestrel(...) to the BuildWebHost function in Program.cs file as follows:

public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.UseKestrel(o => { o.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(10); })
.Build();
}

... Update for .net Core 6 ...

in Program.cs file after

var builder = WebApplication.CreateBuilder(args);

add ConfigureKestrel for WebHost like this

builder.WebHost.ConfigureKestrel(c =>
{
c.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(15);
});

asp.net core 2 Web API timeout issue

adding requestTimeout to web.confg solved my timeout.

<aspNetCore requestTimeout="00:20:00" processPath="dotnet" arguments=".\project.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Better approach is to Kick off request and then poll the result as suggested by @steve-land

.Net Core api long running request

Yes, Azure Load Balancer has a default idle timeout setting of approximately four minutes it’s documented in the FAQ here: https://learn.microsoft.com/en-us/azure/app-service/app-service-web-availability-performance-application-issues-faq#why-does-my-request-time-out-after-230-seconds

Q: Why does my request time out after 230 seconds?

Azure Load Balancer has a default idle timeout setting of four minutes. This is generally a reasonable response time limit for a web request. If your web app requires background processing, we recommend using Azure WebJobs. The Azure web app can call WebJobs and be notified when background processing is finished. You can choose from multiple methods for using WebJobs, including queues and triggers.
WebJobs is designed for background processing. You can do as much background processing as you want in a WebJob.
You could use webjob for your task and see how it goes.

Further, all Azure Web Apps (as well as Mobile App/Services, WebJobs and Functions) run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.
Checkout the GitHub page https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#unsupported-frameworks, which lists the supported and unsupported PDF generators on Azure App Service.



Related Topics



Leave a reply



Submit