> On 14 Nov 2018, at 08:50, Chris Withers <[email protected]> wrote:
>
> Right, so, I've been trying to get the technique in
> https://jml.io/pages/how-to-disconnect-in-twisted-really.html to work for me.
>
> No hating please, most of my testing in the past has involved hitting a
> relational database, so there's already a TCP connection flying around, one
> more won't make any difference.
>
> jml's example, exactly as-is on that page, hangs around 30-40% of the time
> when running on my macOS laptop. From changing the teardown to look like this:
>
> def tearDown(self):
> ds = defer.maybeDeferred(self.serverPort.stopListening)
> dc = defer.maybeDeferred(self.clientConnection.disconnect)
> print()
>
> ds.addCallback(lambda _: print('serverPort.stopListening'))
> dc.addCallback(lambda _: print('self.clientConnection.disconnect'))
> self.clientDisconnected.addCallback(lambda _:
> print('self.clientDisconnected'))
> self.serverDisconnected.addCallback(lambda _:
> print('self.serverDisconnected'))
> self.serverDisconnected.addErrback(lambda _:
> print('self.serverDisconnected:', _))
> return defer.gatherResults([ds, dc, self.clientDisconnected,
> self.serverDisconnected])
>
> ...it appears that it's the serverDisconnected deferred that's failing to
> fire. I can't reproduce this on Linux as of yet, so I'm guessing this is a
> difference between the SelectReactor used on macOS and the EPollReactor used
> on Linux.
>
> What's the best way to go about debugging a non-firing deferred like this?
>
> Anyone know what this might be?
Chris,
I played with this for a bit and quickly reproduced the "server side disconnect
never seems to happen" behaviour you described, on my system running macOS
10.12.6 and Twisted 18.9.0 using the SelectReactor.
Suspecting of an eventual race condition between "server stop listen" and
"server disconnect", I tried this variation of tearDown which seems to work
reliably:
@defer.inlineCallbacks
def tearDown(self):
self.clientConnection.disconnect()
yield defer.gatherResults([self.clientDisconnected,
self.serverDisconnected])
yield defer.maybeDeferred(self.serverPort.stopListening)
Do I have any motive to suspect such race condition? No, but after ensuring
"disconnect first, stop listening later", things work much better here.
Also tested the CFReactor and KQueueReactor: CFReactor seems to exhibit a
similar behaviour (original code hangs every now and then on cleanup, my code
works); KQueueReactor always hangs on cleanup with the original code, and works
reliably with my code.
My 2c.,
--
exvito
_______________________________________________
Twisted-Python mailing list
[email protected]
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
