Hello Jean-Paul, thanks for tracking this down, you rock! I promise that when I'll have payed all by debts I'll buy one of those posters of Exarkun to hang on my wall!
JP wrote: > After a few runs, I managed to reproduce the problem. I instrumented the > reactor with some extra logging and test_producer.py with a manhole server. > The sequence of events appears to be something like this: > > OneA has a producer of OneE > OneA has a consumer of OneB > At some point OneB gives up and tells OneA to stopProducing (loseConnection) > OneA.loseConnection stops the reactor from reading OneA and starts it writing > OneA.doWrite happens > it finds the send buffer empty > it finds a registered producer (OneE) and resumes it > OneE never produces any more bytes > OneE loses its connection at some point and unregisters itself from OneA > OneA takes note that it has no more producer, but does nothing about it > > So the bug is likely that FileDescriptor.unregisterProducer doesn't do > anything special when disconnecting=True. > > You should be able to reproduce this very simply by setting up a > transport-producer/consumer pair, calling loseConnection on the transport, > then unregistering the producer. > > This all sounds somewhat familiar, but I don't see an existing ticket for it, > so maybe that's my imagination. > > Jean-Paul Following your indications I attached a minimal example to a new ticket: http://twistedmatrix.com/trac/ticket/4719 Some additional info: * problem occurs only if more than 64KB of data are written to the transport before its consumer calls stopProducing on it * problem occurs only if some time passes before its producer unregisters itself from the transport Thanks again for your help! :) ste _______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
