MonitorForIdleClientsTask: System.NullReferenceException

[jchristn]

MonitorForIdleClientsTask: System.NullReferenceException

[jchristn]

Thank you @simonhaines I'm looking into this now as well. Cheers!

[jchristn]

Ugh, it shouldn't be going to Console.WriteLine either. My bad.

[jchristn]

I think the issue might be with this: https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.networkstream.close?view=netcore-3.1#:~:text=The%20Close%20method%20frees%20both,dispose%20of%20the%20associated%20TcpClient. Specifically If a NetworkStream was associated with a TcpClient, the Close method will close the TCP connection, but not dispose of the associated TcpClient. I also found:

• https://stackoverflow.com/questions/7617127/does-one-need-to-close-both-networkstream-and-tcpclient-or-just-tcpclient
• https://stackoverflow.com/questions/425235/how-to-properly-and-completely-close-reset-a-tcpclient-connection

I'm closing and disposing the NetworkStream and then also closing and disposing the TcpClient. So it appears I should only be closing the stream but not disposing it.

I'm getting ready to publish an update right now, will link it here.

[jchristn]

Ok, published v2.0.5.

NuGet: https://www.nuget.org/packages/SuperSimpleTcp/2.0.5
Commit: 6ddee98

When you have a moment please let me know if this fixes the issue! (I also got rid of the Console.WriteLine, sorry about that!)

[simonhaines]

Thanks @jchristn, from the look of the patch I think you found the issue is not related to NetworkStream or TcpClient? If it was, I think the exception would be different anyway.

I reproduced it in another run with a logger attached, the relevant events are:

06/25/2020 20:23:42:SimpleTcp: [SimpleTcp.Server] Disconnecting 162.244.250.132:40666 due to timeout
06/25/2020 20:23:42:SimpleTcp: [SimpleTcp.Server] Client 162.244.250.132:40666 disconnected
06/25/2020 20:23:42:SimpleTcp: [SimpleTcp.Server] Data receiver terminated for client 162.244.250.132:40666

I believe this shows two threads interleaving calls to ClientMetadata.Dispose, here and here. The timeout thread begins disposing the client metadata but is suspended. The data receiver thread is then scheduled and successfully disposes of the client metadata. When the timeout thread resumes, the resources have already been nulled.

In any case, I believe the lock is the right approach. I'll try another run and close this issue if there are no more problems.

[jchristn]

Hi @simonhaines is it safe to close? Cheers!

[simonhaines]

Hi @jchristn some more exceptions are turning up in the logs, but I haven't had a chance to trace them yet:

06/26/2020 03:51:25:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:52420
06/26/2020 03:53:38:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:54181
06/26/2020 03:57:59:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:54101
06/26/2020 03:58:33:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:54730
06/26/2020 04:04:09:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:53964
06/26/2020 05:28:37:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:54423
06/26/2020 05:31:52:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:53714
06/26/2020 05:33:03:SimpleTcp: [SimpleTcp.Server] Data receiver socket exception (disconnection) for 162.244.250.132:54207
...many more of the same

(the IP addresses are all the same because I have a single test client)

[jchristn]

Hi @simonhaines yes those are expected and acceptable. These occur during a disconnection.

[jchristn]

Going to close this one for now, please re-open if the issue persists! Cheers