Skip to content
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

Provide deterministic behavior when management.server.port=0 #561

Open
chriswhite199 opened this issue Apr 29, 2019 · 7 comments · May be fixed by #562
Open

Provide deterministic behavior when management.server.port=0 #561

chriswhite199 opened this issue Apr 29, 2019 · 7 comments · May be fixed by #562
Labels
Projects

Comments

@chriswhite199
Copy link
Contributor

As observed in spring-cloud/spring-cloud-consul#555, when using management.server.port = 0 calls to ManagementServerPortUtils.getPort return 0, rather than the dynamic assigned address.

Not sure of the official solution for this, but can ManagementServerPortUtils be extended to add an ApplicationEvent listener and update the port if / when dynamic ports are being used.

Granted there is a potential for a sort-of-race condition here, where a caller might try and get the port value before the application event has fired, but in my experience, the actuator events usually fire before the main application starts.

chriswhite199 added a commit to chriswhite199/spring-cloud-commons that referenced this issue May 1, 2019
chriswhite199 added a commit to chriswhite199/spring-cloud-commons that referenced this issue May 1, 2019
@spencergibb
Copy link
Member

I think that we need to align with what spring boot has done. ManagementServerPortUtils was copied from boot a long time ago. I don't think we want to build something that doesn't work all the time. Maybe @philwebb or @wilkinsona could comment on if there's anything in boot we could take advantage of. The reason for wanting the management port is to register it in service discovery.

@wilkinsona
Copy link
Contributor

We still have logic similar to your ManagementServerPortUtils but that's really intended for figuring out the port configuration and whether or not we need to create the child context for a separate management server. I suspect it's overkill for your needs.

For the purposes of registration with service discovery, I think I'd listen for the WebServerInitializedEvents to retrieve the ports from the events' web servers and the ApplicationReadyEvents to perform the registration. The port values can also be injected via @LocalServerPort and @LocalManagementPort or looked up from the environment using local.server.port and local.management.port but this can only be done safely once the WebServerInitializedEvent has been published. I suspect it's easier just to get the port straight from the event in your case.

@philwebb
Copy link
Contributor

There's a public class in Boot 2.0+ called ManagementPortType that looks very similar to ManagementServerPortUtils.ManagementServerPort but its job is to tell what type of port is needed, not return the actual port number in use. If you want to get the actual port in use you can use the @LocalManagementPort annotation. There's also @ConditionalOnManagementPort that might be useful for conditional beans.

@philwebb
Copy link
Contributor

philwebb commented May 30, 2019

Looks like we both got there at the same time!

@spencergibb
Copy link
Member

I think @ConditionalOnManagementPort could get us part of the way for making decisions on if it is enabled.

Is there a way to tell if WebServerInitializedEvent is for management?

@philwebb
Copy link
Contributor

philwebb commented May 30, 2019

@spencergibb take a look at ServerPortInfoApplicationContextInitializer for an example. The context name is always management I think. See ManagementContextAutoConfiguration

@spencergibb spencergibb changed the title ManagementServerPortUtils.getPort with dynamic port Provide deterministic behavior when management.server.port=0 May 30, 2019
@spencergibb
Copy link
Member

Looks like this could go in Greenwich (so 2.1.x branch) and merged forward.

@spencergibb spencergibb linked a pull request Mar 10, 2021 that will close this issue
@spencergibb spencergibb added this to To do in 2020.0.2 via automation Mar 10, 2021
@spencergibb spencergibb moved this from To do to In progress in 2020.0.2 Mar 15, 2021
@spencergibb spencergibb added this to the 3.0.2 milestone Mar 15, 2021
2020.0.2 automation moved this from In progress to Done Mar 15, 2021
spencergibb added a commit that referenced this issue Mar 15, 2021
@spencergibb spencergibb reopened this Mar 16, 2021
2020.0.2 automation moved this from Done to In progress Mar 16, 2021
@spencergibb spencergibb added this to To do in 2020.0.x via automation Mar 16, 2021
@spencergibb spencergibb removed this from In progress in 2020.0.2 Mar 16, 2021
@spencergibb spencergibb removed this from the 3.0.2 milestone Mar 16, 2021
@spencergibb spencergibb removed this from To do in 2020.0.x Feb 7, 2022
@spencergibb spencergibb added this to To do in 2021.0.x via automation Feb 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging a pull request may close this issue.

6 participants