win32eventreactor doesn't notice TCP connection is lost in certain (hopefully rare) cases
|Reported by:||itamar||Owned by:||exarkun|
branch-diff, diff-cov, branch-cov, buildbot
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.
Change History (29)
comment:5 Changed 5 years ago by exarkun
- Branch changed from branches/win32er-close-5233 to branches/win32er-close-5233-2
comment:9 Changed 5 years ago by itamar
- Keywords review removed
- Owner changed from itamar to exarkun
Changed 5 years ago by zseil
comment:20 Changed 5 years ago by glyph
- Owner changed from glyph to exarkun
- Status changed from assigned to new