En Wed, 12 Dec 2007 13:38:21 -0300, Object01 <[EMAIL PROTECTED]> escribió:
> On Dec 11, 6:17 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> > wrote: >> 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. > The server is multithreaded, handling each request on its own thread. > But is a RST really a part of a valid close operation? No! Sorry, just nonsense. > Looking at the stack, it appears the socket is being closed at the > right time. All data has been sent and the request handler is in its > tear-down phase, expecting no more data from the client (who never > sends any). I don't see different stack traces between error and no- > error requests. Is this applicable in your case?: http://brad.livejournal.com/2152593.html?thread=10832273#t10832273 (closing a nonblocking socket with a nonempty output queue generates a RST) > And on line 156, how is the real socket being deleted? It (the _sock > member) appears to be set to a dummy class that has no real > functionality. Indirectly: if the _sock attribute was the last reference to the real socket object (and that's likely the case), assigning anything to _sock will decrement its reference count to 0, then becoming a candidate for garbage collection. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
