When running on a separate port, Actuator health endpoint may report healthy before the main port is listening

[jjroldan1]

When configuring an application to use a dedicated port for the management endpoints:

management.server.port: 8081

the health endpoint reports "UP" without waiting for the main application port to be exposed. This does not happen when both actuator and application are using the same port, which causes an undesired asymmetry.

This problem can be reproduced easily by having a SmartLifeCycle bean that will be registered to the main application context as is the case when using Spring Cloud Stream with a binding configured (i.e. with Kafka), the InputBindingLifecycle/OutputBindingLifecycle in default configuration will retry for a number of times before failing. During this period, the application has been reported as healthy.

Shouldn't there be an out of the box mechanism for the actuator health endpoint to be aware that the main application port is not yet exposed?

Reproduced with spring boot version: 2.0.3.

[wilkinsona]

I think we should consider reworking the logic that launches the management server so that it only happens once the main web server has been initialised. I've prototyped such a change in this branch. From what I can tell, it seems to work nicely and was a straightforward change. That makes me think I may have missed something…

One thing that the proposed change does lose is the warning when you set a separate management port but deploy your app as a war to a servlet container. There won't be a failure, but management.server.port will be ignored just as server.port is ignored. We had a regression in this area (#14148) in 2.0 where a failure would occur. As long as a failure does not occur, I'm not sure that the loss of the warning is too much of a concern.

Flagging for team attention in case I have missed something and to get the team's opinion on the importance of the warning.

[mbhave]

Is it possible to keep the warning if DifferentManagementContextConfiguration also implements SmartInitializingSingleton and we do the same check that we used to log the warning in afterSingletonsInstantiated?

[wilkinsona]

Yeah, that's possible. We could also listen for another event (ApplicationReadyEvent perhaps) and warn then. I'm more wondering if the usefulness of the warning warrants the extra complexity required to generate it. It's for an edge-case and we don't, IIRC, have similar warnings for when you configure server.* and then deploy as a war file so I am quite tempted to get rid of it.