We have three Spring boot applications:
- Eureka Service
- Configuration server
- Simple web service using Eureka and Config Server
I configured the services so that we use Eureka First Discovery, that is, a simple web application learns about the configuration server from the eureka service.
When starting individually (locally or by launching them as separate docker images), everything is in order, that is, it starts the configuration server after the discovery service starts, and a simple web service starts after the configuration server starts.
When docker-compose is used to start services, they obviously start at the same time and essentially get ready to start and run. This is not a problem, since we added failFast: true and retry values to a simple web service, and also reloaded the docker container so that the simple web service would eventually restart at a time when the discovery service and configuration server were both this does not seem optimal.
The unexpected behavior that we noticed was as follows:
- A simple web service attempts to connect to the discovery service several times. It is reasonable and expected.
- At the same time, a simple web service is trying to contact the configuration server. Since he cannot contact the discovery service, he retries to connect to the configuration server on the local host, for example. logs show that retries go to http: // localhost: 8888 . This was not expected.
- A simple web service will eventually successfully connect to the discovery service, but the logs show that it is still trying to communicate with the configuration server by going to http: // localhost: 8888 . Again, this was not ideal.
Three questions / observations:
- Is it a smart strategy for the configuration client to return to localhost: 8888 when it is configured to use discovery to find the configuration server?
- When eureka connections are established, should the retry mechanism now fail to switch to an endpoint attempt on the configuration server, as indicated by Eureka? Essentially, including higher / longer retry intervals and periods to connect to the configuration server in it is pointless in this case, since it will never connect to it if it looks at localhost, so we better just not work quickly.
- Are there any properties that can override this behavior?
I created a github repo sample that demonstrates this behavior:
https://github.com/KramKroc/eurekafirstdiscovery/ tree / master
source share