Add getPort() or similar to ServerImpl

[buchgr]

I noticed that there doesn't seem to be a way to programatically retrieve a way to get the port a ServerImpl is listening on. Could we add a method that provides this information?

I would argue it's useful for when one wants to bind to port 0 i.e.

ServerImpl server = NettyServerBuilder.build();
server.start()

System.out.println("Server listening on port " + server.getPort());

[ejona86]

Ah! I'm glad someone else is thinking about this! Yeah, port 0 is important to me, too.

Yeah, I've known we've needing something, but there are details. I think providing an InetSocketAddress would make sense. However, it is true that we will have transports that don't use IP: Unix Domain Sockets and shared memory. So port is an aspect of the transport we are using. We could have ServerImpl return a SocketAddress and have the user cast, or we "somehow" expose the methods on the transport directly. I've been working on ideas for the second method, as it could also improve the construction paradigm, but haven't yet gotten anything super-concrete.

[stepancheg]

Any news on the issue? It is super-important for unit-tests. When running unit-tests you need to bind on random port, because otherwize tests occasionally fail giving headaches to developers.

AFAIU, this feature can be implemented easily, it just needs to be decided what API should look like.

I'd prefer ServerImpl to have getPort() function that returns 0 if server is not listening on IP.

[ejona86]

The problem is that not all transports will have a port. The InProcess transport, the Netty-LocalChannel transport, a Unix Domain Socket transport (doesn't exist today, but easily could), and a shared memory transport (also doesn't exist) don't have a port but could use a similar feature. In addition, even normal-Netty could need to provide more than just a port, since it could listen only on particular interfaces.

That still leaves me thinking exposing a SocketAddress on Server may be a pretty reasonable way to go (but I'm also aware of cases that could break down). We should probably just go with SocketAddress, since it is true this has lingered enough.

@stepancheg, note that we do have a workaround in the form of TestUtils.pickUnusedPort(). I will try to delete the method though once this issue is fixed.

[ejona86]

We could maybe also have a getPort() convenience method that gets the SocketAddress casts and gets the port, throwing some exception (IllegalStateException?) or maybe returning -1 if not using ip. I'm not sure how well 0 will work out, since it is a valid argument to InetSocketAddress constructor.

[carl-mastrangelo]

I am marking this as closed, even though there may be more followup work for exposing the SocketAddress.