Thread: Re: Bug (and fix): leaks of TCP connections when connected
There's no finalizer on the Socket class that closes it so that even if it is garbage collected, the socket is not closed at the OS level. I think I saw somewhere this was done by design and actually I believe it's much cleaner to properly close the socket before losing any reference to it so that OS resources are freed as early as possible. Much better for scalability ;-) My java program ran for days so that I'm pretty sure GC occurred. Anyway when I performed a netstat I had hundreds of connections waiting to be closed... Sylvain -----Original Message----- From: Oliver Jowett [mailto:oliver@opencloud.com] Sent: mardi, 22. juin 2004 04:04 To: Laurent Sylvain Cc: 'pgsql-jdbc@postgresql.org' Subject: Re: [JDBC] Bug (and fix): leaks of TCP connections when connected to a <7.4 server Laurent Sylvain wrote: > Hello, > > I experienced some TCP connection leaks when using PGSQL JDBC driver 7.4 > (build 214) to connect to a 7.3.4 server. > The symptoms are that when performing a netstat on the client machine, many > connections were in the CLOSE_WAIT state. > > The problem is that the driver tries to connect using v3 protocol and when > it sees that the server doesn't understand it, it opens a new connection > (PGStream) to the server without closing the previous one: In theory the discarded connections should eventually be garbage collected and closed, right? So at least the leak is bounded. (I'll check that this is fixed in my patches; I restructured that area quite a bit) -O
> There's no finalizer on the Socket class that closes it so that even if it > is garbage collected, the socket is not closed at the OS level. I think I > saw somewhere this was done by design and actually I believe it's much > cleaner to properly close the socket before losing any reference to it so > that OS resources are freed as early as possible. Much better for > scalability ;-) "By design," huh? We call such thinking: bugs on purpose (also known to the anti-MSFT crowd as windows programming). <smile> Yes, it's best to clean up. But no, a finalizer should discard any open resources as that what it was designed for. After all, if the object is GCed, then nobody is using it, so nobody ever will close it. At any rate, sounds like the PG team has already fixed the leak in its code. Thanks guys. David
>> There's no finalizer on the Socket class that closes it so that even >> if it is garbage collected, the socket is not closed at the OS level. >> I think I saw somewhere this was done by design and actually I believe >> it's much cleaner to properly close the socket before losing any >> reference to it so that OS resources are freed as early as possible. >> Much better for scalability ;-) > Our experience here seems to agree with this fact. Either tcp conns aren't close by the GC or it takes too long to do just that. In both cases, we ended with connection leaks. > "By design," huh? We call such thinking: bugs on purpose (also known to > the anti-MSFT crowd as windows programming). <smile> > LOL. I tend to define it as "lazy programming". Like those days in college, when we had to write code that needed to survive only a few minutes, while being screened and tested by our teachers... And that's why I prefer to write code in C. There isn't any Wizard of Oz to do things for you, so, you'd better free your memory by yourself [and close your connections, too]. > Yes, it's best to clean up. But no, a finalizer should discard any open > resources as that what it was designed for. After all, if the object is > GCed, then nobody is using it, so nobody ever will close it. At any > rate, sounds like the PG team has already fixed the leak in its code. > Thanks guys. > Yes, a finalizer should take care (or better care, we just don't know) of this issue. But we're living in a real world, where apps have bugs or design glitches.... Maybe the connection is still referenced by internal (or not so visible) structures so they're never closed/freed automagically.