En Tue, 11 Dec 2007 10:51:13 -0300, Object01 <[EMAIL PROTECTED]> escribi�:
> I've been working with the source code for Trac (http:// > trac.edgewall.org/) lately and have run across a bizarre problem. It > seems that all POST requests to Trac's standalone server (tracd) have > a random chance of causing the server to issue a TCP RST packet that > resets the connection. > > Running Trac 10.3.1 on Win2K3 using Python 2.4, watching traffic with > Wireshark 0.99.5. > > I've been stepping through the code using Winpdb 1.3.2 and have > isolated the problem to the socket.py that's included in Python 2.4. > Line 157, in _socketobject.close(): > > self.send = self.recv = self.sendto = self.recvfrom = > self._sock._dummy > > is what's causing the TCP RST to be issued. If I set a breakpoint on > that line and step over it on a POST request, there's about an 80% > chance the server will issue a TCP RST. When debugging, the entire > response makes it onto the wire before TCP RST is issued. If I'm - > not- debugging, it's anybody's guess as to how much of the response > makes it out. The interruption, when it occurs, always seems to be > between calls to _fileobject.write(). This indicates a timing issue: > perhaps buffered data isn't being waited on properly prior to > the .close() method doing its work. I think the trigger is the line just above that, where the "real" socket is deleted. A RST when you close a socket is OK. From your description it appears that the close method should not have been called at that time; I'd look at the stack and see why is it being called when it shouldn't. I don't believe Python itself randomly calls close() so it looks like a Trac problem, or in the webserver used. Is there any timer used? Is the server multithreaded? -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
