[Python-bugs-list] Re: socket left in FIN_WAIT_2 state (PR#108)

[guido@CNRI.Reston.VA.US]

> Here is the server code.  Your comment about reference counts made me
> want to mention that I am using StreamRequestHandler, which does a 
> makefile() on the socket, but if I read the code correctly, that doesn't
> actually share the socket object?  (Seems to just dup() the fd and make
> a wholly distinct object.)

Correct.  This means that as far as the kernel is concerned the socket
is only really closed when all file descriptors referencing the same
underlying socket connection are closed.  Unless you're squirreling
away copies of self.rfile or self.wfile or self.connection or
self.request, or unless you keep the 'self' object alive longer than
you should (e.g. by creating a circular reference) these should all be 
closed when the objects go away.

...AHA!

I looked at your code (can't really run it, though I tried) and I see
that you create a circular reference by the assignment self.DoQuery =
self.Fetch (and ditto for self.SendResults = self.SendRecords) and
similar assignments later.

This keeps the DBQueryHandler instances alive forever.  This should
explain what you are seeing.

Solution may be as simple as assigning None to self.DoQuery and
self.SendRecords.

Note that your proposed generic solution of closing the socket in
handle_request() in SocketServer.TCPServer won't really work given the 
infrastructure that this class is trying to create -- one could create 
a derived class that overrides get_request() to return a non-socket,
and indeed UDPServer() does this.

Plus, since the rfile and wfile instance variables were still there,
this wouldn't have been enough, probably.

So I conclude it's not a bug and I close the problem report.

--Guido van Rossum (home page: http://www.python.org/~guido/)