在ASP.Net Core 2.0中由于任何原因停止Kestrel时执行瓶坯清理

Question

I'm working on a web application which has multiple threads running which do stuff with sockets and the file I/O. So in the event of the application shutting down, I first want to finish these threads and clean them up.

I already found the following code, which works great in the event of a gracefull shutdown.

public class Startup 
{
    public void Configure(IApplicationBuilder app, IApplicationLifetime applicationLifetime) 
    {
        applicationLifetime.ApplicationStopping.Register(OnShutdown);
    }

    private void OnShutdown()
    {
         // Do your cleanup here
    }
}

But when you have an ungraceful shutdown the OnShutDown() method is not called.

In Forms you can detect all kinds of shutdown reasons with the following code:

private void Form1_FormClosing(object sender, FormClosingEventArgs e)  
{  
    switch (e.CloseReason)  
    {  
        case CloseReason.ApplicationExitCall:  
            // The Exit method of the Application class was called.  
            break;  
        case CloseReason.FormOwnerClosing:  
            // The owner form is closing.  
            break;  
        case CloseReason.MdiFormClosing:  
            // The parent form is closing.  
            break;  
        case CloseReason.None:  
            // Unknown closing reason.  
            break;  
        case CloseReason.TaskManagerClosing:  
            // The application is being closed from the TaskManager.  
            break;  
        case CloseReason.UserClosing:  
            // The user is closing the form through the UI.  
            break;  
        case CloseReason.WindowsShutDown:  
            // Windows is closing the application because it is shutting down.  
            break;  
    }  
} 

Is there anything like this in ASP.Net Core 2.0 to detect any kind of shutdown in stat of only graceful shutdowns?

Answer 1

Event handling is predicated on a successful exit. If you do something like a hard reboot or your application crashes, there's no opportunity to handle anything because it's already gone. That's sort of the point: it was forced to exit, so it can't do anything.

That said, the issue here is either not actually an issue or a design problem. First, if the process exits, the threads go with it. There's nothing to "cleanup". Socket handles and such are just pointers in memory, they too go with the process.

If the process is hanging, that's a different story. In that situation, it can hold on to resources, since it's still technically running. However, then, the true issue is fixing whatever is causing the process to hang, not figuring out how to release resources when it does.

Bear in mind that a web server is designed to quickly respond to incoming requests. It should be an almost instantaneous process. It's not designed to chew on requests for a while, doing a bunch of work. If you need to do things like connect to sockets and such, that should very likely be offloaded into an external process, like a console application, windows service, etc. Then, your web application can simply hand off work to this and move on. You can provide an endpoint to check for status, progress, etc., and use that via SignalR or AJAX long-polling to update the client about the progress of the work/notify them when it's done.