Underlying socket is not closed if Akka.IO TCP connection timeouts

[isurakka]

Running this code for 7-14 minutes on my computer causes you to run out of sockets.

The problem appears to be in TcpConnection or SocketChannel. Looks like TcpConnection checks if SocketChannel is open by calling IsOpen but it returns false even if the socket is bound therefore the socket is never closed.

[alvarezdaniel]

I'm observing the same behavior if I send a Tcp.Connect message to the internal TcpConnection actor, and it cannot connect. If I make a loop trying to connect with no successful operation (no server responding to the connection), In ProcessExplorer I can see that a file handle to "\Device\Afd" is created and it is not released for each connection retry. TcpConnection actor is not closing SocketChannel object, which contains the reference to Socket object. After many retries, the system runs out of handles (sockets).

[Danthar]

Is this issue already Addressed in the akka.io branch ? @akkadotnet/core

[alvarezdaniel]

I've tested in Akka.IO branch, and the problem is gone. In source code I can see that socket object is disposed successfully.

[alvarezdaniel]

Hello, just a question. When this issue could be merged to main branch and included in a new release? Because in Akka.IO branch is working right, but new release (1.2.0) still has this problem.

[Aaronontheweb]

@Horusiath was this fixed in your latest set of commits for 1.3?

[alexvaluyskiy]

I think we did not fix this issue. I run the example and got a problem with sockets. @Aaronontheweb, @alvarezdaniel, @isurakka Could you re-check it with the nightly nugets, please?

[Horusiath]

We solved several IO related issues including: #3211, #3188 and several others since the latest release. We need to reevaluate this issue. @Aaronontheweb maybe could help here, as he has product using Akka.IO on production ;)

[Aaronontheweb]

@Horusiath we haven't seen any issues like this since the Akka.NET v1.3.2 release, since we did the socket IO rewrite in 1.3.0 and patched some of the issues with socket sends in 1.3.1 and 1.3.2. Going to close this one since I think it's been solved.

[mivacode]

Hi Team, I am observing a leaking handles issue in our environment running version 1.3.5 referenced from nuget. Handles in process explorer are named "\Device\Afd" like in original post by @alvarezdaniel. I double checked this in windbg (!gchandles) and I can see a large number of "Async Pinned Handles".
Is it likely that the problem has been reintroduced in 1.3.5 version?

[Aaronontheweb]

@mivacode it's possible, have any way of reproducing the issue similar to what was originally described?

[mivacode]

@Aaronontheweb when I ran your test code with 1.3.5 and did not observe leaking handles. I think our circumstances are slightly different. Since the issue occurred in prod I need to work on reproducing in locally before I can provide more details.