Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

IApplicationShutdown.RequestShutdown is does not serve the outstanding requests but dies #31

Closed
Praburaj opened this issue Sep 26, 2014 · 10 comments
Assignees
Labels
Milestone

Comments

@Praburaj
Copy link
Contributor

Related# aspnet/HttpSysServer#71

Send a request to the application. It is expected to serve the outstanding requests and die. This works as expected on Helios.

On Kestrel the event seems to be honored, but the outstanding request is not served. The host process simply gets killed.

On weblistener this event is not being honored. This item tracks the issue for weblistener: aspnet/HttpSysServer#71

public void Configure(IApplicationBuilder app)
 {
app.UseServices();
app.Run(async context =>
                {
                    Console.WriteLine("Received shutdown request...");
                    var appShutdownToken = context.ApplicationServices.GetService<IApplicationShutdown>();
                    appShutdownToken.RequestShutdown();

                    try
                    {
                        if (!appShutdownToken.ShutdownRequested.IsCancellationRequested)
                        {
                            await Task.Delay(10 * 1000, appShutdownToken.ShutdownRequested);
                        }
                    }
                    catch (Exception exception)
                    {
                        Console.WriteLine(exception);
                    }

                    if (appShutdownToken.ShutdownRequested.IsCancellationRequested)
                    {
                        await context.Response.WriteAsync("Shutting down gracefully");
                    }
                    else
                    {
                        await context.Response.WriteAsync("Shutting down token not fired");
                    }
                });          
  }
@Praburaj Praburaj added the bug label Sep 26, 2014
@Tratcher
Copy link
Member

@muratg
Copy link
Contributor

muratg commented Jul 23, 2015

I assume this bug is still valid?

@halter73

@muratg
Copy link
Contributor

muratg commented Jul 23, 2015

Yup, just checked with @anurse (who was playing with Kestrel) and Ctrl-C kills the process.

@muratg muratg added this to the 1.0.0 Backlog milestone Jul 23, 2015
@muratg
Copy link
Contributor

muratg commented Sep 24, 2015

This is graceful shutdown (draining remaining requests after shutdown.)

@DamianEdwards Do you want this in RC1? Pull to RC1 milestone if so.

@DamianEdwards
Copy link
Member

I think post-RC is OK for this one.

@cesarblum
Copy link
Contributor

I had to rewrite @Praburaj's code since a few things have changed since this issue was filed. I rewrote it as:

app.Run(async context =>
{
    Console.WriteLine("Received shutdown request...");
    var appLifeCycle = context.RequestServices.GetService<IApplicationLifetime>();
    appLifeCycle.StopApplication();

    try
    {
        if (!appLifeCycle.ApplicationStopping.IsCancellationRequested)
        {
            await Task.Delay(10 * 1000, appLifeCycle.ApplicationStopping);
        }
    }
    catch (Exception exception)
    {
        Console.WriteLine(exception);
    }

    if (appLifeCycle.ApplicationStopping.IsCancellationRequested)
    {
        await context.Response.WriteAsync("Shutting down gracefully");
    }
    else
    {
        await context.Response.WriteAsync("Shutting down token not fired");
    }
});

I can't repro the original issue. Kestrel shuts down gracefully after the request is received (the browser shows the respose Shutting down gracefully).

Let me know if I'm missing something here.

@cesarblum cesarblum added 2 - Working and removed bug labels Dec 14, 2015
@cesarblum
Copy link
Contributor

Closing since it's an old issue that does not repro anymore.

@yousifh
Copy link

yousifh commented Dec 22, 2015

Hi,

Maybe I'm misunderstanding the purpose of StopApplication() function, but if I do something like the following (on RC1-update1 on Windows with clr runtime)

app.Run(async context =>
{
    Console.WriteLine("Received shutdown request...");
    var appLifeCycle = context.RequestServices.GetService<IApplicationLifetime>();
    appLifeCycle.StopApplication();

    try
    {
        if (!appLifeCycle.ApplicationStopping.IsCancellationRequested)
        {
            await Task.Delay(10 * 1000, appLifeCycle.ApplicationStopping);
        }
    }
    catch (Exception exception)
    {
        Console.WriteLine(exception);
    }

       // Replace this with something that does long work, or maybe Task.Delay()?
    long total = 0;
    for (long i = 0; i < 9999999999; i++)
    {
        total =  i;
    }

    Console.WriteLine("Done?");

    if (appLifeCycle.ApplicationStopping.IsCancellationRequested)
    {
        await context.Response.WriteAsync("Shutting down gracefully");
    }
    else
    {
        await context.Response.WriteAsync("Shutting down token not fired");
    }
});

It never prints "Done?" on the console or shows "Shutting down gracefully" on the browser assuming of course it actually takes a relatively long time on your machine to go through the loop. Is StopApplication() supposed to make sure this thing completes its processing before it shuts down the process or no?

Doing something like await Task.Delay(TimeSpan.FromSeconds(5)); has the same effect but again, I'm not sure if StopApplication() is meant to wait for this to finish before shutting down.

@halter73
Copy link
Member

@yousifh If you remove the for loop do you see "Done?" and "Shutting down gracefully"?

Kestrel will not wait indefinitely for the application function to complete. In RC1-update1, I think it gives the app about 2.5 seconds to finish.

@yousifh
Copy link

yousifh commented Dec 29, 2015

@halter73 Yeah, it works fine once I remove the for loop. I wasn't aware the timeout Kestrel had while it waits to close down. I can see the 2.5 seconds timeout in KestrelEngine when it tries to stop each KestrelThread. Thanks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

7 participants