Stream ReadAsync stuck bug
See original GitHub issueHi, I got the bug when after timeout the client connection was not closed, it hangs for long time inside ReadAsync. Even when cancellation token was raised. I see your notice in the MqttTcpChannel.Dispose() method about stream disposing, but it should be like:
_stream?.Dispose();
_stream = null;
_socket?.Dispose();
_socket = null;
Disposing only _stream does not cancel ReadAsync in my case, so _socket should be also disposed.
Issue Analytics
- State:
- Created 4 years ago
- Comments:19 (1 by maintainers)
Top Results From Across the Web
Stream ReadAsync stuck bug · Issue #584 · dotnet/MQTTnet
Hi, I got the bug when after timeout the client connection was not closed, it hangs for long time inside ReadAsync.
Read more >ReadAsync stops code execution, no exception is thrown ...
So I'm connecting to a proxy server with my C# program using the TcpClient class. I establish the connection and just keep reading...
Read more >ReadAsync: Continuously reads stream and spits out Packets
I am creating a server client app where after the connection is done, the server and client will send packages back and forward....
Read more >NetworkStream.ReadAsync Method (System.Net.Sockets)
Reads data from the NetworkStream and stores it in a byte memory range as an asynchronous operation.
Read more >C# 6.0 Cookbook: Solutions for C# Developers - Google Books Result
try { // Buffer for reading data byte[] bytes = new byte[1024]; StringBuilder clientData = new StringBuilder(); Stream stream = null; if (!string....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

I maybe found a reason. I added a UnitTest but it worked as expected. The socket was disposed perfectly. The stream will dispose the socket internally on its own dispose. The hierarchy is
NetworkStream > Socket. But when I checked the chain for SSL connections it was broken. The hierarchy isSslStream > Networkstream > Socket. So the disposal of the SSL stream should close the networks stream and the network stream should dispose the socket. But this was broken because of wrong parameters for stream constructors. That`s why you needed to dispose the socket. Are you using SSL connections? Or is this maybe another issue?The fix is already pushed to develop branch.
Test that and latest builds, seems its ok now with secure connection.