Can DotNetty socket exception include information about the address?

[object]

We noticed that sometimes when we restart an Akka.NET-based Windows service, it fails to to start due to reuse of a socket address. It usually starts on a next attempt even though more attempts may be required. This is quite strange situation, like socket address it not released promptly after the previous service instance terminates. To research the situation more we would like to find out what address is failing, but the exception doesn't say that. The call stack and message are like this:

CoreCLR Version: 5.0.20.51904
.NET Version: 5.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AggregateException: One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (Only one usage of each socket address (protocol/network address/port) is normally permitted.)))))
---> System.AggregateException: One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (Only one usage of each socket address (protocol/network address/port) is normally permitted.))))
---> System.AggregateException: One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (Only one usage of each socket address (protocol/network address/port) is normally permitted.)))
---> System.AggregateException: One or more errors occurred. (One or more errors occurred. (Only one usage of each socket address (protocol/network address/port) is normally permitted.))
---> System.AggregateException: One or more errors occurred. (Only one usage of each socket address (protocol/network address/port) is normally permitted.)
---> System.Net.Sockets.SocketException (10048): Only one usage of each socket address (protocol/network address/port) is normally permitted.
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at DotNetty.Transport.Channels.Sockets.TcpServerSocketChannel.DoBind(EndPoint localAddress)
at DotNetty.Transport.Channels.AbstractChannel.AbstractUnsafe.BindAsync(EndPoint localAddress)
--- End of stack trace from previous location ---
at DotNetty.Transport.Bootstrapping.AbstractBootstrap2.DoBindAsync(EndPoint localAddress) at Akka.Remote.Transport.DotNetty.DotNettyTransport.NewServer(EndPoint listenAddress) at Akka.Remote.Transport.DotNetty.DotNettyTransport.Listen() at Akka.Remote.Transport.DotNetty.DotNettyTransport.Listen() --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification)
at System.Threading.Tasks.Task`1.get_Result()
at Akka.Remote.Transport.AbstractTransportAdapter.<>c__DisplayClass11_0.<b__0>d.MoveNext()

And here is the failing code in DotNettyTransport.cs:

        protected async Task<IChannel> NewServer(EndPoint listenAddress)
        {
            if (InternalTransport != TransportMode.Tcp)
                throw new NotImplementedException("Haven't implemented UDP transport at this time");

            if (listenAddress is DnsEndPoint dns)
            {
                listenAddress = await DnsToIPEndpoint(dns).ConfigureAwait(false);
            }

            return await ServerFactory().BindAsync(listenAddress).ConfigureAwait(false);
        }

BindAsync is outside Akka.NET code (it's a part of DotNetty) but can NewServer or DotNettyTransport.Listen wrap the code in an exception handler that will enrich (or log) error information with listenAddress? What do you think?

[Aaronontheweb]

@object yeah this should be easy to fix. I'll submit a PR.

[Aaronontheweb]

Need a review on #5132, but I think that should do it