Aspnetcore: Application Initialization *stops* working for .NET Core

Created on 2 Mar 2020  路  3Comments  路  Source: dotnet/aspnetcore

Describe the bug

Per https://github.com/dotnet/aspnetcore/issues/3849 and https://github.com/dotnet/AspNetCore.Docs/issues/16675, there are scenarios when App Init stops working entirely for .NET Core processes.

Warmup.dll is loaded into IIS, and attempts to look for an endpoint at the website (e.g. if I tell it the preload URL is (site)/start, ProcMon reveals warmup searching for (Websitefolder)/start), but fails.

My intention is to run background tasks within the same .NET Core MVC project, which helps enormously with code consolidation, while maintaining responsibility separation.

To Reproduce

Reproduction is difficult. I have several servers in which this behavior occurs, but it appears to only start happening after some period of time (publishing to the endpoint many times, Windows Updates in between, etc.).

Reinstalling IIS and registering App Init/.NET Core modules temporarily resolves the issue.

Further technical details

I don't know what is needed to proceed - I can provide details of places where this continues to fail.


Current Workaround: Run some out-of-proc task to run any harmless MVC min at X frequency - this starts the dotnet process as expected. (e.g. Scheduled Task that sends a request for (WEBSITE)\start every 5min)

affected-few area-servers bug severity-major

Most helpful comment

Just FYI - this still happens with latest IIS and .NET Core - seems common, and basically invalidates existing MSFT docs that say this is a good option for background .NET Core services..

All 3 comments

Just FYI - this still happens with latest IIS and .NET Core - seems common, and basically invalidates existing MSFT docs that say this is a good option for background .NET Core services..

I just tried this guy's solution, and it worked for me, but I do not understand why it works:

In my case, lack of Garbage Collecting was making the problem. I traced the memory usage and it got increased by any page load. I just added this to my .csproj file:
<PropertyGroup> <ServerGarbageCollection>true</ServerGarbageCollection> <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection> </PropertyGroup>
and the problem got solved.

_Originally posted by @mobinseven in https://github.com/dotnet/aspnetcore/issues/11950#issuecomment-520295866_

Can anyone clue me in to any possible side effects from this? For what it's worth I deployed this in my project on Friday, came in this morning, and my app ran successfully all weekend. I can see in the logs that it is still shutting down, but then it starts right back up again, which is the behavior that I expect.

@unionthugface - This might explain some oddities, though complete lack of garbage collection seems like a top-priority sort of issue - is there a separate ticket for that? EDIT: Saw the linked issue, thank you for opening. I'm not sure what verification they are looking for, but basically any background service registration that relies on AppInit within IIS gets the issue..

I had surmised that this problem was due to some bridge/integration issues between IIS and Kestrel, which if this solves would reinforce - I will try this out, as my temporary (aka until now permanent) solution has been to run a "start" call to the WebAPI on IIS every 5min to make sure the background services run.

Since I'm guessing they will have to run memory profiling to verify that the GC is having issues, I can also try to do the same

Was this page helpful?
0 / 5 - 0 ratings

Related issues

guardrex picture guardrex  路  3Comments

markrendle picture markrendle  路  3Comments

BrennanConroy picture BrennanConroy  路  3Comments

aurokk picture aurokk  路  3Comments

groogiam picture groogiam  路  3Comments