Fixed CPU / memory issue caused by infinite loop caused by ReadByte retu...#61
Fixed CPU / memory issue caused by infinite loop caused by ReadByte retu...#61mburnell wants to merge 2 commits intosmiley22:masterfrom
Conversation
…eturning data always when connection is dropped.
|
This looks interesting, but could you recreate this pull request with the same indentation and coding style as existing code? |
|
My apologies - I was stumbling my way through first-time Git usage and didn't spot the inconsistent whitespace. I've brought it into line with the rest of the file now. |
|
Thanks! Shouldn't TcpClient or NetworkStream error out though if the connection is dropped? What actually happens if the connection is dropped and you call ReadByte on a NetworkStream? I would think it'd throw an exception..or does it just return -1 to indicate end of stream? Can you resubmit to the experimental branch? Then we can do some testing there and then merge into master. cheers, |
|
Sorry for such a slow reply. I don't know what happens with raw NetworkStream objects; if they throw exceptions, then great. The issue is that the stream may be an SslStream which (under some conditions) does NOT throw exceptions OR return -1 during a read operation... it just keeps returning non-negative integers indefinitely, leading to an infinite loop. The CheckConnection method I added interacts with the stream in a way that doesn't suffer from (what I consider to be) this bugged behaviour. To reproduce it I had to programmatically disable my network adapter on another thread while the call was running, and the timing was reasonably sensitive (I think the timing window was significantly less than 100ms). The issue is pretty serious; we had at least one production environment encounter it, and besides being trapped in a loop and not receiving emails, it completely saturated a thread and led to rapid memory allocation / collection cycles. You can move the changes across to your experimental branch if you want, but I've no interest in that branch; we'll continue using our own branch until an equivalent fix makes its way into master. |
...rning data always when connection is dropped.
Issue #60