Hello Jean-Paul, thanks for looking into this. >>What did make a difference was to comment this line, the problem >>never happens without it: >> >>to.transport.registerProducer(_from.transport, True) > > This suggests that your problem is that you don't unregister the > produce. The connection can never be closed as long as a producer is > registered. Does your code ever unregister this producer?
I am 100% sure that I unregister the producer from the transport right before I call loseConnection on that transport (see code snippet in my original post). Even using reactor.callLater for calling loseConnection asynchronously after the producer has been unregistered didn't help. Moreover, if it was just a problem of my code not unregistering the producer then this wouldn't explain why registering the producer as non-streaming fixes the issue. It also wouldn't explain why does this happen only in particular conditions and not always (even if I managed to reproduce it reliably, I still have to debug the exact external conditions that trigger it). As a side note, for once what you wrote is not 200% exact ;) because the connection is always closed properly if it's the peer closing it first, even if the producer is still registered in that case. (Maybe Twisted unregisters the producer by itself when this happens?) Anyway, I ran Twisted tests on my installation after the patch I mentioned in my previous mail and I got the same results as before applying it so at least it seems it doesn't break any obvious stuff. thank you, ciao ste _______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
