Ticket #5233 defect closed fixed
win32eventreactor doesn't notice TCP connection is lost in certain (hopefully rare) cases
|Reported by:||itamar||Owned by:||exarkun|
(diff, github, buildbot, log)
http://twistedmatrix.com/trac/browser/branches/abortConnection-78-7/twisted/internet/test/test_tcp.py?rev=32436#L1413 -- test_resumeProducingThrows -- demonstrates the win32eventreactor problem: it doesn't notice a lost TCP connection. The problem doesn't appear to have anything to do with the abortConnection call; the test still fails if that line is commented out.
Protocol A connects over loopback to Protocol B. Protocol A's resumeProducing gets called from its transport's doWrite; resumeProducing throws an exception. At this point we expect the following to happen:
- Exception thrown from resumeProducing is logged, and Protocol A has its connectionLost called.
- Protocol B, which is connected to A over TCP, should also get its connectionLost called.
While item 1 happens, item 2 does not. As far as I can tell, MsgWaitForMultipleObjects never notices that B has lost its connection.
Only workaround I found: making the socket close with SO_LINGER set to 1,0, i.e. force RST instead of FIN. In this case MWFMO does notice the connection was lost.