Comment 8 for bug 1282089

> Therefore, unless we can fix every circular reference, we have to manually release resources that need to be, since the __del__
> method isn't even called. For that purpose, the close() method allows us to do that explicitly.

You don't have to run gc.collect() manually the GC will free them automagically (if there is no __del__ method b/c this break gc circular reference collector) when the object threshold that he track is reached and such, but yes like i said we should not relay on the GC that the reason of this bug report b/c in the end stuff fail :)

 > @mouadino, FMPOV, the issue is not fully related to the use of connection pools. I think that we would have the same issue with
 > bare opened files that are never closed. Besides, if an application only uses one keystoneclient at a time, the Session class should
 > be instanciated only once at a time, unless the client isn't released - which is what happens. I don't think that we have to disable
 > connection pools (they may be useful if the Session object is used by several clients, like keystone, nova, ...), but I do think that
 > we have to release these resources properly when they are not used anymore.

True but if there was no connection pooling Requests will be closing the socket for us (because they will not be used for pipeline), like i said it because it does connection pooling that's why it doesn't close the socket, and of course it does close socket if this one are part of the pool overflow (https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/connectionpool.py#L245) or maybe we can just use HTTP 1.0 this way the server will close the request, which also another lost for us.