Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kestrel now reacts to configuration changes by default #22807

Closed
halter73 opened this issue Jun 11, 2020 · 1 comment
Closed

Kestrel now reacts to configuration changes by default #22807

halter73 opened this issue Jun 11, 2020 · 1 comment
Labels
affected-very-few This issue impacts very few customers area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions feature-kestrel severity-nice-to-have This label is used by an internal tool task
Milestone

Comments

@halter73
Copy link
Member

Kestrel now reacts to configuration changes by default

Kestrel now reacts to changes made to the "Kestrel" section of the application's IConfiguration (e.g. appsettings.json) at runtime. To learn more about how to configure Kestrel using appsettings.json, see the appsettings.json example in https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel#endpoint-configuration.

Kestrel will bind, unbind and rebind endpoints as necessary to react to these configuration changes.

Version introduced

ASP.NET Core 5.0.0-preview7

Old behavior

Prior to 5.0.0-preview6, Kestrel did not support changing config at runtime.

In 5.0.0-preview6, you could opt into the now-default behavior of reacting to configuration changes at runtime by binding Kestrel's configuration manually as follows:

webHostBuilder.UseKestrel((builderContext, kestrelOptions) =>
{
    kestrelOptions.Configure(builderContext.Configuration.GetSection("Kestrel"), reloadOnChange: true);
});

New behavior

Kestrel now reacts to configuration changes at runtime by default.

Reason for change

To support reconfiguring endpoints at runtime without completely restarting the server. Unlike with a full server restart, unchanged endpoints are not unbound even temporarily.

Recommended action

For the majority of scenarios where Kestrel's default configuration section does not change at runtime, this change has no impact and no action is needed.

For scenarios where Kestrel's default configuration section does change at runtime and Kestrel should react to it, this is now the default behavior.

For scenarios where Kestrel's default configuration section changes at runtime and Kestrel should not react to it, you can opt out as follows:

webHostBuilder.UseKestrel((builderContext, kestrelOptions) =>
{
    kestrelOptions.Configure(builderContext.Configuration.GetSection("Kestrel"), reloadOnChange: false);
});

Notes

This does not change the behavior of the KestrelServerOptions.Configure(IConfiguration) overload which still defaults to the reloadOnChange: false behavior.

It's also important to make sure the configuration source supports reloading. For Json sources this is done by calling AddJsonFile(path, reloadOnChange: true). This is already done by default for appsettings.json and appsettings.{Environment}.json.

Category

ASP.NET

Affected APIs

This is the discussion issue for the following announcement: aspnet/Announcements#419


Issue metadata

  • Issue type: breaking-change
@ghost
Copy link

ghost commented Jan 12, 2021

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

@ghost ghost closed this as completed Jan 12, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Feb 11, 2021
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Jun 2, 2023
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affected-very-few This issue impacts very few customers area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions feature-kestrel severity-nice-to-have This label is used by an internal tool task
Projects
None yet
Development

No branches or pull requests

4 participants