Maven Plugin: integration tests (start) expects registered port 9001 to be free for JMX, fails cryptically otherwise ("Failed to retrieve RMIServer stub: javax.naming.CommunicationException")

[Chealer]

Following a change of PC-s, my team was unable to start its Spring Boot application due to an error. Thanks to my colleague, we figured out that this is due to a common and well-known conflict for port 9001. Thanks to ticket #22401 , section 8.3.2 of the Maven plugin reference now documents a simple workaround.

Obviously, we should never expect a port we haven't registered to be free, but such an expectation is particularly problematic with port 9001. Port 9001 is officially registered for "ETL Service Manager", but this appears to be an old product no longer in usage. In practice though, this number is very tempting, and has several usages according to Wikipedia:

• Microsoft SharePoint authoring environment
• Tor network default
• DBGp Proxy
• HSQLDB default port

And apparently, the Intel Graphics Command Center Service now also binds to port 9001 (as discussed in this Microsoft forums thread and in this similar issue report). This is why the port is already in use on our PC-s. Note that the Intel Graphics Command Center Service is on our organization's laptops even though I see no sign of the Intel Graphics Command Center.

And to make it even worst, the part which attempts to bind port 9001 visibly has no error-checking at all. Therefore, it's only when the client tries to connect to it that the failure appears, and at this point, it's not pretty. Rather than a usual "Could not bind to port x" message, we get a message which even a senior developer like myself may not understand:

[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.2.2.RELEASE:start (default-cli) on project [...]: Could not contact Spring Boot application: Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: non-JRMP server at remote endpoint]

This was apparently introduced in commit 54e12a0 and affects the Maven plugin of Spring Boot 2.2.2 (but the changelog gives no indication that this would be fixed as of 2.3.4).

Ideally, Spring Boot would not try to open any registered port, but would instead either register one or use a dynamic port. But if that's not easy, it would help a lot meanwhile to detect failure earlier, so that the error message is reasonably clear.

[snicoll]

Unfortunately, we can't allocate a random port as two goals need to know about it (not only start but also stop obviously) and we don't want to start hacking the Maven lifecycle to pass that information around. As you've noticed yourself, there is a clear example of what you should do if the port is taken in the documentation (not really a workaround though).

Having said all of that, we could post-process the exception and provide better hints when such failure occurs.

[Chealer]

Thanks @snicoll ,

Unfortunately, we can't allocate a random port as two goals need to know about it (not only start but also stop obviously) and we don't want to start hacking the Maven lifecycle to pass that information around.

Right... I don't know Maven, but I do expect a proper fix to require a significant effort, which is why I offered a mitigant meanwhile.

As you've noticed yourself, there is a clear example of what you should do if the port is taken in the documentation (not really a workaround though).

Yes... can you clarify if there is an issue with the workaround?

Having said all of that, we could post-process the exception and provide better hints when such failure occurs.

That's exactly the kind of trap I wanted developers to avoid... I described a reliable (as well as efficient) way to mitigate in the last paragraph. To clarify, what detecting earlier means is to perform error checking on the initial unsafe operation (binding on the hijacked port) rather than when things really go wrong, when trying to connect to that port later.

[snicoll]

Yes... can you clarify if there is an issue with the workaround?

As I've mentioned already, it isn't a workaround. Why would there be an issue with something that's documented and supported? If that port is used, take another port.

We'll use this issue to improve the error message and hint users that the port is already taken.

[Chealer]

Hi @snicoll ,

Yes... can you clarify if there is an issue with the workaround?

As I've mentioned already, it isn't a workaround. Why would there be an issue with something that's documented and supported? If that port is used, take another port.

Ah, I understand what you meant now. Obviously there is an issue if that wastes people's time, but surely what you meant to ask is why it's a defect. The bug is not that the current design can't work, it's just that it violates standards (making it unreliable) to use that design (with port 9001) without registering the port Spring tries to use (see Wikipedia for an explanation of port ranges). I am not sure what you mean by "supported", but regarding documentation, that does not justify hijacking a registered port (I mean, if there was a warning before users downloaded Spring Boot, that would arguably excuse it, but documenting somewhere in an "Examples" section as it currently stands is very far from that).

We'll use this issue to improve the error message and hint users that the port is already taken.

Yes, as indicated in my last comment, that would mitigate, and if we're going to take months to ship an actual solution, this would in fact greatly diminish the impact.

[wilkinsona]

@Chealer Unfortunately, registering a port won't make any difference as you've demonstrated with your examples above. 9001 is registered, yet, excluding Spring Boot, there are at least 5 different pieces of software that use it. Any port that we may switch to or that we may register may already have conflicting uses or would become conflicted in the future. Given that we can't prevent a port clash, the only solution to this issue that I can see is to improve the error message when a clash occurs. As described above, this is already what we intend to do to resolve this issue.

[Chealer]

Hi @wilkinsona ,

@Chealer Unfortunately, registering a port won't make any difference as you've demonstrated with your examples above. 9001 is registered, yet, excluding Spring Boot, there are at least 5 different pieces of software that use it. Any port that we may switch to or that we may register may already have conflicting uses or would become conflicted in the future.

I understand your reasoning, which is logical. In practice though, registering would (with a minimum of luck) make quite a difference. You are completely correct that registering a port does not guarantee there will be no conflict. Nevertheless:

1. Registering a port (and changing the port used) would stop the current conflict(s) and make the plugin standards-compliant.
2. The risk of future conflicts is not equal for all ports. Basically, conflicts on registered ports happen due to coders who do not really understand networking or who just never learned it. Those will tend to pick a "random" port, if it turns out to work on their system. They will tend to choose a "random" number which is easy to remember or communicate to the other side. Wikipedia's list shows that the most misused ports have simple numbers. For example, between 8000 and 10000, we see 8000, 8008, 8080, 8090, 8123, 8200, 8333, 8880, 8888, 9000, 9001, 9080, 9090, 9800 and 10000. You can trust me that the average registered port has much less conflict potential than port 9001.

Given that we can't prevent a port clash, the only solution to this issue that I can see is to improve the error message when a clash occurs. As described above, this is already what we intend to do to resolve this issue.

Just to be clear, that would help a lot, but that is technically not a solution to the issue. In terms of actual solutions, the 2 main options are:

• using a port registered for that purpose
• using a dynamic port

And please note that although I "defended" registration above, I am not recommending to register a port for this. I would much prefer to see this solved by usage of a dynamic port (which would have the advantage of avoiding any risk of the conflicts you pointed out).

P.S. I clarified the issue bringing the title closer to its original form. Thanks for the edit and feel free to improve it further, but please try to keep enough elements so that others searching have a fair chance of finding it, and phrased as an issue report rather than as a request.