Application context keeps refreshing for cloud config server after fixed duration

[get2parag]

The spring application context gets refreshed after fixed interval of time ~15s.
Issue#1 -- I would like to know if this is desired behavior to reload the context continously. Does @EnableConfigServer keeps polling for the configurations? If not what is the way to disable it. I see it happens due to the health check but using property "spring.cloud.config.server.health.enabled=false" did not have any affect.
Issue#2 -- This causes extra noise in the logs as well. Any way to disable them apart from putting custom filter in logback?

Spring boot version:- 1.3.5.RELEASE
Spring cloud version:- 1.0.4.RELEASE

Example logs:-

2016-06-23 16:03:35,526 INFO  [XNIO-3 task-126] org.springframework.context.annotation.AnnotationConfigApplicationContext - Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@50b345ea: startup date [Thu Jun 23 16:03:35 IST 2016]; root of context hierarchy
2016-06-23 16:03:35,528 INFO  [XNIO-3 task-126] org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor - JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
2016-06-23 16:03:35,550 INFO  [XNIO-3 task-126] org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@50b345ea: startup date [Thu Jun 23 16:03:35 IST 2016]; root of context hierarchy
2016-06-23 16:05:20,763 INFO  [XNIO-3 task-133] org.springframework.context.annotation.AnnotationConfigApplicationContext - Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@715e3d3a: startup date [Thu Jun 23 16:05:20 IST 2016]; root of context hierarchy
2016-06-23 16:05:20,766 INFO  [XNIO-3 task-133] org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor - JSR-330 'javax.inject.Inject' annotation found and supported for autowiring

[spencergibb]

Config server does not do polling. Do you have config clients that get /health pinged every 15s?

[get2parag]

Apologies for replying late here.
Yes we have consul which regularly does the health check for all services including the config-server as well. Will check for any config client doing it as well.
But I'm surprised why simple health check refreshes the application context.

[get2parag]

@spencergibb do you think I've to develop another health check point for consul in this case to avoid application refresh or we can achieve this by any other means?

[get2parag]

Adding some debug information:-
While doing ConfigServer health check in ConfigServerHealthIndicator, there is a call to findOne environment which internally which creates and refreshes the application context via SpringApplication class.

[get2parag]

Solved this temporarily by disabling the config-server endpoint for now, applying spring.cloud.config.server.health.enabled=false in bootstrap.yml. Earlier I applied in application.yml but it did not work as had a dependency of spring cloud config in my project.

Keeping this issue open as I'm waiting to see if refreshing / reloading the spring application context is avoidable while doing a health check.

[ekfliu]

I also getting this issue where did you put spring.cloud.config.server.health.enabled? this is not valid properties in my config application or my client application? why would consul health check make config reload entire context? this does not make any sense.

[spencergibb]

@ekfliu it's pretty clear the answers to your question in the comments above.

spring.cloud.config.server.health.enabled=false in bootstrap.yml

The health check of the application tries to get configuration from config server, it consul is pinging /health every 10 seconds it will get config from config server every 10 seconds. It doesn't reload the entire context. See #260 for conversation about if the health check should be enabled by default or not.

[ekfliu]

okay but the issue is spring.cloud.config.server.health.enabled is not considered to be a valid property in my application in both the config or the client application. I put the settings in anyway but it does not stop the config refresh.

This application originally uses eureka and works fine. but after moving to consul i kept getting this intermittent timeout on my zuul proxy service. I am not sure if this is related to config refreshing or not, but trying to remove all the variables to debug this issue.

[ekfliu]

okay looks like you need it on both on the config server and the client application.

Thanks

[ekfliu]

okay the actual settings that i got it to work is health:config:enabled: false in the application.yml for both the config server and the client application. now when manually hitting the url http://your-service/health used by consul it no longer check the server for new configs.
Thanks Again.

[ezraroi]

Hi all, one thing that i didn't get yet from the answers.
Why the configuration service is recreating the application context again and again every few seconds... I have a standalone configuration service which get timeout when i try to call it because it is refreshing the application context all the time

[spencergibb]

@ezraroi that's an implementation detail of how config server works. Something is hitting it every few seconds. Likely a monitoring solution hitting /health of clients.

[ezraroi]

@spencergibb i understand this, but isn't it possible to do the health check without recreating the context? If there is no such case i think it is better to not allow it at all as this makes the configuration service to become not responsive

[spencergibb]

@ezraroi it's not the main application context.

[ezraroi]

@spencergibb , ok.. but still looks like it is making the configuration service very loaded and prevents it to answer calls

[spencergibb]

Config server does not do polling. Do you have config clients that get /health pinged every 15s?

[ezraroi]

Yes , i had... i disabled this after reading in this issue.. It helped reducing the load from the configuration service

[spencergibb]

Can we close this then?

[ezraroi]

looks like yes