I've been battling a problem with 7.6 recently that I hadn't had in the 7.5 versions I'd previously been running.
My code creates, over time, a large number of short lived Protocol.LDAP.client objects. The problem that I'm having is that even if I explicitly destruct these objects, I end up with a large number of sockets that are in CLOSE_WAIT state. Eventually, this number of sockets increases to the point where I run out of FDs. The only way to clear the sockets completely is to call gc(), which I've resorted to every 5 minutes through a call out to solve the problem.
To me, this sounds like a problem. Anyone else have any thoughts?
Bill
That could be my doing in revision 1.54, provided you get it with ldaps. It gave SSL.sslfile an Fd object, which it doesn't take (never has, not even in the old implementation).
Since Stdio.File is inherited, the correct argument therefore is this, which makes a nice cycle since it's stored back in ldapfd in protocol.pike. That inherit looks bogus to me, but since I don't know the territory I only fixed the type error.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-05-26 22:23: Subject: Stdio.File sockets not getting closed in 7.6
I've been battling a problem with 7.6 recently that I hadn't had in the 7.5 versions I'd previously been running.
My code creates, over time, a large number of short lived Protocol.LDAP.client objects. The problem that I'm having is that even if I explicitly destruct these objects, I end up with a large number of sockets that are in CLOSE_WAIT state. Eventually, this number of sockets increases to the point where I run out of FDs. The only way to clear the sockets completely is to call gc(), which I've resorted to every 5 minutes through a call out to solve the problem.
To me, this sounds like a problem. Anyone else have any thoughts?
Bill
/ Brevbäraren
I wish I could say that was it, but I'm not using ldaps. I'm not completely sure where the problem crept in; a periodic gc() makes it livable, if not great.
Bill
On Wed, 26 May 2004, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
That could be my doing in revision 1.54, provided you get it with ldaps. It gave SSL.sslfile an Fd object, which it doesn't take (never has, not even in the old implementation).
Since Stdio.File is inherited, the correct argument therefore is this, which makes a nice cycle since it's stored back in ldapfd in protocol.pike. That inherit looks bogus to me, but since I don't know the territory I only fixed the type error.
/ Martin Stjernholm, Roxen IS
Open fd:s in garbage is very bad. Do you think you could make an attempt at locating the cyclic structure? In cases like this I usually do
call_out (_locate_references, 30, suspect_object);
where suspect_object in your case is a Protocol.LDAP.client object and 30 is a time large enough so that the object ought to be gone by then. If everything is as it should be, the only ref to it is from the call out itself, so your suspect refs are those other than that which _locate_references reports. Note that rtldebug is necessary to get _locate_references.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-06-04 16:37: Subject: Re: Stdio.File sockets not getting closed in 7.6
I wish I could say that was it, but I'm not using ldaps. I'm not completely sure where the problem crept in; a periodic gc() makes it livable, if not great.
Bill
On Wed, 26 May 2004, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
That could be my doing in revision 1.54, provided you get it with ldaps. It gave SSL.sslfile an Fd object, which it doesn't take (never has, not even in the old implementation).
Since Stdio.File is inherited, the correct argument therefore is this, which makes a nice cycle since it's stored back in ldapfd in protocol.pike. That inherit looks bogus to me, but since I don't know the territory I only fixed the type error.
/ Martin Stjernholm, Roxen IS
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Martin Stjernholm, Roxen IS ＠ Pike developers forum