I've discovered a race condition in TextClient.Disconnect and TextClient.SendCommand that is happening about once a day (program runs 24/7). Turns out the idle code (or something) must be calling the SendCommand function while disconnect is disposing of the SSL stream, resulting in a ThreadException being raised when it attempts to write to the stream.
I'm not really sure of the best way to handle this so I've just attempted to hack around it for now by catching an ObjectDisposedException and carrying on like nothing happened. Here are the exception details
Cannot access a disposed object.
Object name: 'SslStream'.
at System.Net.Security.SslState.CheckThrow(Boolean authSucessCheck)
at System.Net.Security.SslState.get_SecureStream()
at System.Net.Security.SslStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at AE.Net.Mail.TextClient.SendCommand(String command) in D:\Documents\CODE\aenetmail\TextClient.cs:line 98
at AE.Net.Mail.ImapClient.OnLogout() in D:\Documents\CODE\aenetmail\ImapClient.cs:line 481
at AE.Net.Mail.TextClient.Logout() in D:\Documents\CODE\aenetmail\TextClient.cs:line 43
at AE.Net.Mail.TextClient.Disconnect() in D:\Documents\CODE\aenetmail\TextClient.cs:line 119
at AE.Net.Mail.TextClient.Dispose() in D:\Documents\CODE\aenetmail\TextClient.cs:line 134
Looks like the order of operations was wrong in the Dispose() method. The connections were being shutdown before Disconnect() and Logout() had run. Fixed in commit #50f0959d80.
I've discovered a race condition in TextClient.Disconnect and TextClient.SendCommand that is happening about once a day (program runs 24/7). Turns out the idle code (or something) must be calling the SendCommand function while disconnect is disposing of the SSL stream, resulting in a ThreadException being raised when it attempts to write to the stream. I'm not really sure of the best way to handle this so I've just attempted to hack around it for now by catching an ObjectDisposedException and carrying on like nothing happened. Here are the exception details