Not sure exactly what's causing this, but my config server is getting hammered with requests from applications that are running and when I check the application logs I see multiple config fetches per minute, here's one app's log file for example:

2015-10-15 14:39:31.072  INFO 25849 --- [nio-8082-exec-6] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:40:02.067  INFO 25849 --- [nio-8082-exec-8] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:40:11.072  INFO 25849 --- [nio-8082-exec-9] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:40:45.084  INFO 25849 --- [nio-8082-exec-1] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:40:46.442  INFO 25849 --- [nio-8082-exec-5] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:41:17.943  INFO 25849 --- [nio-8082-exec-7] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:41:21.565  INFO 25849 --- [nio-8082-exec-6] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:42:01.791  INFO 25849 --- [nio-8082-exec-8] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888
2015-10-15 14:42:12.491  INFO 25849 --- [nio-8082-exec-9] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://{config server host}:8888

Here's what my bootstrap.yml looks like for all apps:

spring:
  application:
    name: {app name here}
  cloud:
    config:
      failFast: true
      uri: http://{config server host}:8888
      username: {removed}
      password: {removed}

I would expect the config clients to only request configs at startup and when /refresh is called. Is this a bug or have I missed some configuration option?

Looking at the code it seems when failFast is set a RetryOperationsInterceptor kicks in, but it should only retry 6 times by default. I am not familiar with how these interceptors work though, so this may or may not be related:

https://github.com/spring-cloud/spring-cloud-config/blob/master/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigServiceBootstrapConfiguration.java#L70

Comment From: spencergibb

There is nothing that polls from the client side.

If you meet the following conditions, then yes (but only if it can't connect).

If you expect that the config server may occasionally be unavailable when your app starts, you can ask it to keep trying after a failure. First you need to set spring.cloud.config.failFast=true, and then you need to add spring-retry and spring-boot-starter-aop to your classpath.

Comment From: jordanjennings

Forgot to mention I'm using Brixton.BUILD-SNAPSHOT and also using Eureka.

Looks like there's a health check that's running periodically that's causing the problem. In ConfigServerHealthIndicator.doHealthCheck it is calling ConfigServicePropertySourceLocator.locate which pings the config server.

Now I'm just trying to determine what's causing the health check. Does Eureka hit the /health endpoint? I thought clients just sent a heartbeat every 30 seconds.

Comment From: spencergibb

If eureka.client.healthcheck.enabled=true then it uses the health check do determine the status to send to eureka during the heartbeat. It is not enabled by default.

Comment From: jordanjennings

Found the issue. We have a monitoring app that's calling /health for all the apps periodically. Is there any way to disable the config server part of the health check?

Comment From: spencergibb

Awesome: health.config.enabled=false.

Comment From: jordanjennings

You rock, thanks for the quick replies!

Comment From: jordanjennings

FYI - looks like all the health.* properties have been renamed to management.health.* per:

http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/html/common-application-properties.html

Will they be renamed here as well?

Comment From: spencergibb

Potentially, but that's what is is named right now.

Comment From: PBLTS

The my project configuration server client is displaying a difference to build, because when it is started by STS, the cloud: config: failFast: true uri: http://config-server:9888 property is visible to the maven of the build, but it is stardet to java -jar project.jar the initiator is the default location: 8888. The mvn spring-boot: run command is ok, but my business structure needs to work with java -jar. Can you help me configure config when started with jjar -jar. Thank you

bootstrap.yml spring: application: name: project-name cloud: config: failFast: true uri: http://config-server:9888

eureka: instance: preferIpAddress: true leaseExpirationDurationInSeconds: 2 leaseRenewalIntervalInSeconds: 2 client: registerWithEureka: false fetchRegistry: false serviceUrl: defaultZone: ${EUREKA_URI:http://eureka-server:9761/eureka}

Comment From: Swatikp

health.config.enabled=false

Should it be mentioned in spring config server application or spring config client?

Comment From: prasad1007

@Swatikp it should be in client, please check below : https://cloud.spring.io/spring-cloud-static/spring-cloud-config/1.3.1.RELEASE/ They mentioned this under tag Health Indicator