Thread: Re: Bug (and fix): leaks of TCP connections when connected

Re: Bug (and fix): leaks of TCP connections when connected

From
Laurent Sylvain
Date:
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

Re: Bug (and fix): leaks of TCP connections when connected

From
"David Wall"
Date:
> 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


Re: Bug (and fix): leaks of TCP connections when connected

From
"Marcus Andree S. Magalhaes"
Date:
>> 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.