When Tomcat starts up and finds an already deployed WAR file containing the Eureka server, the startup of this web application hangs for about two minutes after this log:
o.s.c.n.eureka.InstanceInfoFactory : Setting initial instance status as: STARTING
After some debugging I found that starting the Eureka server also initializes the client in EurekaServerAutoConfiguration#peerAwareInstanceRegistry. Upon client initialization, a request is performed against the currently starting Eureka server. Tomcat seems to block such a request during its own startup, causing the application to pause for about two minutes. This does not happen when starting my application with "bootRun" or redeploying the WAR in Tomcat once it has been started.
I am using Tomcat 10.1.4, Spring Boot 3.0.0 and Spring Cloud Netflix 4.0.0.
Comment From: spencergibb
Do you mean this line? https://github.com/spring-cloud/spring-cloud-netflix/blob/fa07416bd84e93f06f3a44ee5104b657cf911fa7/spring-cloud-netflix-eureka-server/src/main/java/org/springframework/cloud/netflix/eureka/server/EurekaServerAutoConfiguration.java#L202
Maybe there could be a property that you could set when deploying to a WAR? We don't test WAR deployment of eureka server.
Comment From: spring-cloud-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: windmueller
Do you mean this line?
Yes, exactly.
Maybe there could be a property that you could set when deploying to a WAR?
A property for Eureka would be great, since there does not seem a way to configure this behavior in Tomcat.
Comment From: spencergibb
Thanks for the clarification, PRs welcome.
Comment From: RobertBleyl
PR is open now.
Comment From: RobertBleyl
PR is open now.
Further investigation showed that the initial idea does not fix the issue, therefore I closed the PR again. We will continue our investigation.
Comment From: RobertBleyl
A new PR is open now which fixes the issue we are having. The "getApplications()" needs to be skipped both for the server and the client in our case.
Comment From: RobertBleyl
It does not seem that the PR has been reviewed yet. Can you tell if this could happen soon? This is important for our Jakarta migration.
Comment From: RobertBleyl
I created a new PR that is based on the current main branch (after the 4.1.0 release). We would appreciate any feedback on this! Are there any issues preventing the PR from being merged?