Maximum value of spring.cloud.config.server.git.refresh-rate

[Mamtha3005]

Hi,

May I know the maximum value I can set for spring.cloud.config.server.git.refresh-rate? Isit
spring.cloud.config.server.git.refresh-rate=100000000??

Hope you could provide me with the actual value that I can use.

For some context: I use config server for my application to retrieve yml files that are not frequently updated. Hence, I do not need config server to refresh very often, I can refresh it manually using the /refresh endpoint. Hence, in other words, I prefer disabling the refresh rate by setting the maximum value. Let me know what value I can use, thanks

[ryanjbaxter]

I think if you set it to a negative number it will disable refresh entirely
https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/JGitEnvironmentRepository.java#L473

[Mamtha3005]

When setting the refresh rate to -1, instead of accessing the cached files, I see that config servers tries to access the configurations files in bitbucket repo for every request instead. Setting to -1 does not work.

[markranullo]

I think if you set it to a negative number it will disable refresh entirely https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-server/src/main/java/org/springframework/cloud/config/server/environment/JGitEnvironmentRepository.java#L473

It clearly says in the code that it may only skip refreshing if refreshRate is greater than 0 at line 473.

if (this.refreshRate > 0 && ...) {...}

[ryanjbaxter]

Yup you are right, I was reading the code quickly and misread it.

The property is an int so I suppose the max value you can use is the max value of an int. Although I can't say I tried that

[markranullo]

I think it would be good to have -1 as a means to disable refresh rate while allowing the config server to serve configurations without querying remote git server for every config request, which can be very inefficient otherwise, on use cases where it is expected to have many requests to configurations.

Consider the following use case.

You have an app where, depending on some inputs, it would pull specific configuration from config server every time. There is going to be hundreds of configurations. It essentially sees config server as repository of configurations and it's being used as like any other APIs. It treats the configuration as data that contains business rules or logic and not just application configuration which is usually only needed on startup.

I'm presuming this is a valid use case. I'd would like to hear if this isn't the intended purpose of config server.