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.