Update: I added a routine dataReceivedBufLen() to the LineReceiver class and call it to check if there is any pending data when the lost connection callback is called on the connection. There is no pending buffered data when the connection is lost. This implies I am using twisted properly, and maybe the bug is in the program on the other end of the connection.
Thanks, Arun --- On Fri, 6/10/11, A Desai <[email protected]> wrote: From: A Desai <[email protected]> Subject: Re: Debugging truncated response.. (REPOST to fix newlines) To: [email protected] Date: Friday, June 10, 2011, 3:49 PM I am trying to debug a scenario wherein a program has an http channel/transport that receives an HTTP response; and in some cases (5 out of 10,000) the channel/transport invokes the lost connection callback while the amount of data received is less than the content length. The connection is used as a producer to write to another connection. I am trying to debug to check whether: (1) the last chunk (20K+) of data sitting in the incoming response is not being propagated up, e.g. due to a prior pauseProducing() call, or (2) the data was not sent from the peer (e.g. connection closed without using so_linger) In general, I "presume" lost connection callback on a producer socket would not be called if there is pending (paused) data that has yet to be written a consumer (socket). I am also assuming that the assert in internet/abstract.py::resumeProducing() [self.connected and not self.disconnecting] is valid. I.E: If someone can confirm that scenario (1) above is not possible in twisted (unless a bug). By the time the lost connection callback is called, the transport channel is gone. I would have to instrument either tcp.py, basic.py, or abstract.py to track this. Any clues/suggestions welcome. Thanks. -Arun
_______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
