It appears that in discovery-first mode, the config client is not updating its location information for the config server when that data changes in eureka (i.e. when a config server instance is removed or added in eureka). Is this currently expected behavior, or am I doing something wrong?
my bootstrap config:
spring:
cloud:
config:
enabled: true
failFast: true
discovery:
enabled: true
eureka:
client:
serviceUrl:
defaultZone: [[my eureka defaultZone]]
When I take down the first config server instance, the configserver healthcheck in the app begins to fail despite there being a second working node registered with eureka. The same occurs if I restart the config server node with a new password in the eureka metadataMap, in which case the client keeps trying to use the old password.
Comment From: spencergibb
spring.cloud.config.discovery.enabled=true is currently built on a one time eureka lookup. It is not built with ribbon (ie a client-side load balancer).
Comment From: whboyd
Is this something that you might like to see a PR on?
Comment From: spencergibb
Yes, we'd want to make sure it's well tested and easy to understand.
Comment From: whboyd
I'll give it a shot
Comment From: superwen0001
DiscoveryClientConfigServiceBootstrapConfiguration heartbeat event triggers the refresh config. Uri. It holds EurekaClient is old, the EurekaClient should be a singleton, but the introduction of the config is created twice, causing it to refresh for the config address is still not available
Comment From: xiaods
any update?
Comment From: vnicers
any update?
Comment From: madogao
+1 any update?
Comment From: ryanjbaxter
If there was an update it would have been posted here
Comment From: lahcloud
any update?
Comment From: xiaobai1202
any update ?
Comment From: bberto
I think the analysis done here can be useful spring-cloud/spring-cloud-netflix#3675
During startup a DiscoveryClient is created on bootstrap context and then shut down. Then DiscoveryClient is restarted, but ConfigServerInstanceProvider continues to use the shutdown bean, getting no updates.
This makes discovery-first bootstrap working only if config server is already registered on Eureka when config client starts.
Comment From: nikfuri
I have same issue with ReactiveEurekaDiscoveryClient. It is configured with DiscoveryClient which is used during bootstrap, then this client is shut down and never refresh, and loadbalancer never gets instances updates.
Comment From: k631583871
You can subscribe to the spring-cloud/spring-cloud-netflix#3675 questi
Comment From: spencergibb
There's no need to comment on multiple issues. GitHub links them automatically.
Comment From: pivotghub
I this issue fixed now ? If yes then which version we can follow ?
Comment From: OlgaMaciaszek
Avoid using EurekaClient in order to fix this issue and the following issues in SC Netflix: #3708, #3675.