Support for Targeted Property Refresh in /actuator/refresh Endpoint

[samuelj90]

Question :

Hello @spring-cloud-issues, @spring-cloud Team,

I'm currently using the Spring Boot Actuator's /actuator/refresh endpoint to refresh my application's properties. However, I've noticed that the endpoint triggers a full refresh of all property sources. The issue with this approach is that some encrypted properties always cause Spring beans to reinitialize.

I wanted to confirm if there's any support for a more granular refresh mechanism, where specific properties or beans can be targeted for refresh instead of reloading the entire property source. If this isn't supported, are there any plans to introduce this feature in future releases?

[ryanjbaxter]

No there is no granular mechanism to do so. I am not entirely sure it would be possible to do so as I believe the refresh endpoint reinitializes the application context. In addition I think this may introduce some problems when we have properties that depend on other properties. If a property contained within a property sources gets refreshed and there is a property within another property source that does not get refreshed but references property's which value was changed it would no longer have the correct value.

[samuelj90]

@ryanjbaxter / @spring-cloud-issues, @spring-cloud Team,

Thanks for responding. I am quite confused on where to open issue. that's why created on the other project too. Thanks for clearing it out.

In the absence of a granular refresh mechanism, are there any recommended workarounds to minimize the impact of reinitialize beans due to encrypted properties from your end. Are there any detailed resources or documentation that explain the inner workings of the /actuator/refresh endpoint and its impact on the application context? It finds difficult to get more understanding from the documentation.

My understanding on the actuator refresh is as follows

The /actuator/refresh endpoint in Spring Boot Actuator is used to refresh the application context, allowing the application to pick up changes in the configuration properties without restarting the entire application.
When a request is made to the /actuator/refresh endpoint, Spring Boot triggers a refresh of the application context.
The refresh process involves re-binding beans that are annotated with @ConfigurationProperties or @RefreshScope. This means that these beans will be re-initialized with the latest configuration properties. Also the new beans generated after refresh happens will have new value,

I don't understand your concern on the issues that will cause due to the granular mechanism. My ask is simple If we are able to pass an optional request body with the specific properties to be refreshed to the /actuator/refresh endpoint Those values will get updated in the local property sources and rest changes will get un affected. ie it refreshes or recreates @ConfigurationProperties or @RefreshScope beans and newly creating beans. When endpoint /actuator/refresh endpoint without a body it will refreshes all the properties from last hit without affecting the changed properties.

Could you please provide more insights or suggestions on this approach?

[samuelj90]

@spencergibb /@dwen77 / @zhenbianshu / @qdaxb / @andrew-yang / @spring-projects-issues /@martin-tarjanyi / @FrontierPsychiatrist / @OlgaMaciaszek /@wind57 Do any of you have any recommendations on this? Commenting for better visibility.

[ryanjbaxter]

My main concern would be something like this...

foo=bar
hello=${foo}

What if you only refresh foo without refreshing hello?

Maybe you can be more specific about your concern about the Beans being reinitialized. What is the problem you are experiencing when this happens?

[samuelj90]

@ryanjbaxter
In addressing this issue, my initial thought is to implement a straightforward solution, although I am cautious about potential consequences. It's crucial to ensure that the environment is re-evaluated after updating the specific properties. This can be accomplished by fetching the entire environment context and re-evaluating only the property placeholders that depend on the inputted values.

My thought process for this feature as it adds values to multiple team managing the configuration concurrently. Where one team update the configuration and hitting refresh will not get impacted to other team's configuration changes.
This especially can happens when cloud config clients integrated to vault.

[ryanjbaxter]

My thought process for this feature as it adds values to multiple team managing the configuration concurrently. Where one team update the configuration and hitting refresh will not get impacted to other team's configuration changes.

So there is shared configuration values between apps/teams? I am confused how eventually all apps won't eventually get the updated configuration.

Or is it the case that multiple teams are updating the configuration of a single app? Again eventually the app will a complete refresh of its configuration once the app restarts at some point.

[samuelj90]

@ryanjbaxter

For me app restart is out of scope of the refresh endpoint. I mean multiple team updating configuration of a single application.

[ryanjbaxter]

For me app restart is out of scope of the refresh endpoint

Yes but once the apps restarts it will essentially act like a full refresh and all properties will be updated in which case the problem you are trying to avoid will happen.

[samuelj90]

@ryanjbaxter

Our goal with the refresh endpoint is to avoid restarting the application. Therefore, we prefer not to mix the two approaches.

Additionally, when using the refresh endpoint, we want to ensure that only the intended configuration changes are applied, without incorporating changes made by others.

[ryanjbaxter]

Additionally, when using the refresh endpoint, we want to ensure that only the intended configuration changes are applied, without incorporating changes made by others.

But again EVENTUALLY these changes will be applied. The other teams could use the same selective refresh mechanism to apply their changes for example. The app will also eventually be restarted. So this doesn't really solve the problem.

[samuelj90]

I still don’t understand why we are mixing two things together.

The primary aim of the actuator refresh endpoint is to make configuration changes in the environment without restarting the application.

Currently, our strategy is to refresh everything at once which is similar to restart itself. One of the main issues with this approach is the uncertain impact on the application.

To mitigate this issue, we can consider a selective refresh instead of a full refresh.

Selective refresh can be done at:

Property source level
Property level, and so on.
I understand your point about restarts, but we are aiming for high availability with minimal restarts. That’s why we rely on the refresh endpoint.

[ryanjbaxter]

I mean multiple team updating configuration of a single application.

So when team one updates configuration values and does a partial refresh and then team two updates configuration values and then does a partial refresh won't you run into the same issue as doing a full refresh?