ServerInitializer blocks Tomcat startup for two minutes

[windmueller]

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.

[spencergibb]

Do you mean this line?

spring-cloud-netflix/spring-cloud-netflix-eureka-server/src/main/java/org/springframework/cloud/netflix/eureka/server/EurekaServerAutoConfiguration.java

Line 202 in fa07416

this.eurekaClient.getApplications(); // force initialization

Maybe there could be a property that you could set when deploying to a WAR? We don't test WAR deployment of eureka server.

[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.

[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.

[spencergibb]

Thanks for the clarification, PRs welcome.

[RobertBleyl]

PR is open now.

[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.

[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.

[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.

[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?