This is inspired by some of the servers from the Javascript world where the servers have become pretty smart to suggest an alternative available port in case the port specified is already in use.
Comment From: wilkinsona
Thanks for the suggestion. Can you please link to some examples from the JavaScript world of how this works? Unfortunately, I am struggling to imagine how it would be useful.
If you've configured the server to use a specific port, I expect that you would want it to use that specific port. On the other hand, if you're happy for the server to use any free port, you can already set server.port to 0 and an ephemeral port that is guaranteed to be available will be allocated.
Comment From: quaff
Find available port from default 8080 if server.port is not explicit set. for example 8082 will be used if both 8080 and 8081 in use.
Comment From: wilkinsona
Thanks, @quaff. I understood that's what it would do, but I do not understand why that's useful. If you want your server to listen on 8080, what is the benefit of it using 8082 instead? As I said above, I'd like to see some examples from the JavaScript world to help me to understand the utility.
Comment From: quaff
If you want your server to listen on 8080, what is the benefit of it using 8082 instead?
8082 will be used if server.port is not specified, If I want my server to listen on 8080, I should configure server.port=8080.
The benefit from my experience is firewall friendly, port range 8080-8089 is normally listened by http server in whitelist of network administrator.
NOTE: I'm not sure my requirement is same as smart suggested from javascript world.
Comment From: bclozel
Finding available ports is also unreliable, this is why SocketUtils has been removed from Spring Framework in the first place. I agree with Andy here.
We do have a failure analyzer that let developers know if the port is already taken. Often the port is already busy because the application is already running. Starting it on a different port is just likely to confuse people at development time: you've just made changes and you can't see those on the original port because the new instance started on a different one.
@quaff I think you've over-interpreted @s9m33r 's suggestion as they're mentioning suggest an alternative available port, not actually start the server on a different port.
Comment From: quaff
@bclozel I'm stating my suggestion not interpreting s9m33r's suggestion.
I suggest take an default port range instead of one fixed default port, I don't care which particular port is using, so there is no original port, take any available 808* port and log it.
Comment From: wilkinsona
@quaff please don't hijack the issue any further. Let's wait and hear from @s9m33r please.
Comment From: s9m33r
Hey folks, the idea was rather simpler and more of a convenience. I observed this behaviour with the React Native server:
The server goes as far as to tell you what's running on the configured port.
The reason we might need this is, say we've a default port 8080 configured for our API and that's occupied by another API. It would be so much more convenient if we can just say to an alternate suggestion.
Probably, once we encounter a PortInUseException we can try to recover in this way.
Comment From: philwebb
I could see how this could possibly be a useful devtools addition, but personally I think the negatives currently outweigh the positives. We don't currently have any user interaction when an app starts, so it's not possible to ask the user if they want to try a different port. Without that, we're going to need to pick a port and report it which is pretty similar to using port 0 currently.
Thanks anyway for the suggestion, but I'm going to close this one for now. We can reconsider if we every get a more interactive startup experience with devtools.