Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Websocket: Prevent panic on Disconnect/Connect
Previously we'd set the websocket to disconnected when *either* of the Conn/AuthConn got a disconnect message. This meant that: * The other connection was still functioning * A user would be free to call Connect() * wsReadData() may not have exited Any call to Connect would be acceptable, and we'd probably get a panic from the underlying shared/re-used gorilla websocket: `panic: runtime error: slice bounds out of range [:13501] with capacity 8192` when a new wsReadData goro is started and the old tries to ReadMessage as well, overallocating the buffer. This wouldn't normally occur because trafficMonitor would see traffic (on either connection) and then set the websocket to being connected again. The solution is to treat a Disconnect on either websocket as a call to Shutdown the whole websocket, and then trafficMonitor can reconnect it properly. Unit Testing for this has been difficult. So far I've had to rely on a disruption inside websocket's connectionMonitor itself to reproduce the panic, but from there it's been very consistent. Depends on thrasher-corp#1466
- Loading branch information