New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use REST API for registration in Eureka #3795
Comments
|
Is this something that you might like to see a PR on? |
Yes, we'd want to make sure it's well tested and easy to understand. |
I'll give it a shot |
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 |
any update? |
1 similar comment
any update? |
+1 any update? |
If there was an update it would have been posted here |
any update? |
any update ? |
I think the analysis done here can be useful #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. |
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. |
You can subscribe to the spring-cloud/spring-cloud-netflix#3675 questi |
There's no need to comment on multiple issues. GitHub links them automatically. |
I this issue fixed now ? If yes then which version we can follow ? |
This eliminates the oddness of having multiple discovery client beans and related behavior. Fixes gh-3795 See spring-cloud/spring-cloud-gateway#1514
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:
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.
The text was updated successfully, but these errors were encountered: