java.net.BindException on startup can result in spurious log messages

[jamesnetherton]

Describe the bug

I was playing with some Camel Quarkus code and was wanting to force an error scenario. So I configured a Netty TCP route to listen on port 8000, which I had already bound to something else. The application correctly fails on startup with java.net.BindException. But the accompanying log messages are confusing.

ERROR [io.qua.run.Application] (main) Port 8080 seems to be in use by another process. Quarkus may already be running or the port is used by another application.
WARN  [io.qua.run.Application] (Quarkus Main Thread) Use 'netstat -anop | grep 8080' to identify the process occupying the port.

In this case, port 8080 is not in use by another process.

Expected behavior

The log messages are either not present in this scenario or reference the correct port.

Actual behavior

Log messages are output as described in the bug description.

How to Reproduce?

1. If you have netcat installed, bind to port 8000.

nc -l -p 8000

2. Modify quickstart grpc-plain-text-quickstart by adding configuration property quarkus.grpc.server.port=8000.
3. Then start the application mvn quarkus:dev.

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.6.2.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[geoand]

This isn't actually an error, because what Quarkus is reporting is that the conflict on the HTTP "server"

[jamesnetherton]

This isn't actually an error, because what Quarkus is reporting is that the conflict on the HTTP "server"

If the error message states Port 8080 seems to be in use by another process when it clearly isn't. How is that not incorrect / misleading?

[geoand]

I thought you were starting Quarkus for both processes. Now I read the description more carefully.
Indeed the warning is misleading.

[famod]

@geoand I think in VertxHttpRecorder.doServerStart() we should throw a custom BindException which contains the exact info which port (and which property) is affected and remove all that guesswork from ApplicationLifecycleManager.
WDYT? I could add it to my list.

[geoand]

Yeah, absolutely. BindException should contain the port, so we should definitely use it

[geoand]

#23186 takes care of the issue