Hi,
I noticed that when the .NET server is running with active WebSocket connections, trying to shut it down (e.g. with Ctrl+C or SIGTERM) is delayed for around 30 seconds because of these hanging connections. The server doesn't terminate right away.
I believe the shutdown process should automatically close all active WebSocket connections gracefully.
It seems that the default ShutdownTimeout for the ASP.NET Host is 30 seconds. When I lowered it in Program.cs:
builder.Services.Configure<HostOptions>(options =>
{
options.ShutdownTimeout = TimeSpan.FromSeconds(7);
});
the timeout worked as expected. However, the HttpContext.RequestAborted cancellation tokens are only triggered after this shutdown timeout expires. And from what I gathered this is the place where all Decoders are waiting for here (I also see that HttpContext.RequestAborted token is used in other places so all of those need to be updated as well)
Would you be open to a bugfix/feature that improves WebSocket shutdown behavior by making disconnection depend not only on HttpContext.RequestAborted, but also on IHostApplicationLifetime.ApplicationStopping (via a linked CancellationTokenSource)?
This could be introduced as an opt-in feature to avoid changing existing behavior and maintain full backward compatibility.
Hi,
I noticed that when the .NET server is running with active WebSocket connections, trying to shut it down (e.g. with Ctrl+C or SIGTERM) is delayed for around 30 seconds because of these hanging connections. The server doesn't terminate right away.
I believe the shutdown process should automatically close all active WebSocket connections gracefully.
It seems that the default ShutdownTimeout for the ASP.NET Host is 30 seconds. When I lowered it in Program.cs:
the timeout worked as expected. However, the
HttpContext.RequestAbortedcancellation tokens are only triggered after this shutdown timeout expires. And from what I gathered this is the place where all Decoders are waiting for here (I also see that HttpContext.RequestAborted token is used in other places so all of those need to be updated as well)Would you be open to a bugfix/feature that improves WebSocket shutdown behavior by making disconnection depend not only on
HttpContext.RequestAborted,but also onIHostApplicationLifetime.ApplicationStopping(via a linked CancellationTokenSource)?This could be introduced as an opt-in feature to avoid changing existing behavior and maintain full backward compatibility.