Here are the sequence of events:
- we disconnect
- The disconnect timer beings to run (so no longer scheduled), but doesn't set likelyExpired yet
- We connect, and set likelyExpired = false
- The disconnect thread runs and sets likelyExpired to true, and it is never set back to false (note that we cancel the disconnect thread but that only cancels scheduled tasks but not running tasks).
This is pretty difficult to reproduce without doing more work in the disconnect thread. It's easy to reproduce by adding sleeps in various places – I have a test that I'll attach that does that.
The most straightforward way to solve this would be to grab the synchronization lock on ConnectionManager in the disconnect thread, ensure we aren't actually connected, and only then setting likelyExpired to true. In code:
but this is all pretty subtle and error prone. It's easier to just get rid of the disconnect thread and record the last time we disconnected. Then, when we check likelyExpired, we just do a quick calculation to see if we are likelyExpired.
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Resolution||Fixed [ 1 ]|