|
Home > Archive > Perlbal > October 2007 > max_idle_time of zero - leaked fds?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
max_idle_time of zero - leaked fds?
|
|
| John Berthels 2007-10-08, 1:12 pm |
| Hi,
I'm seeing quite a few old (>10000 secs) Perlbal::ClientHTTPBase
sockets in state reading_headers (from the 'socks' output).
Am I right in thinking that all the classes which inherit from
Perlbal::Socket have a max_idle_time of 0 and so never time out? So if
someone did a TCP connect to perlbal client-facing port and then
dropped off the net (so the socket never became readable after the
connect), we'd leak an fd into state?
Or is there another fd reaping mechanism apart from
Perlbal::Socket::_do_cleanup? Or have I misunderstood the code (I'm
looking at current svn here, r706).
regards,
jb
| |
| Mark Smith 2007-10-08, 7:11 pm |
| >
> I'm seeing quite a few old (>10000 secs) Perlbal::ClientHTTPBase
> sockets in state reading_headers (from the 'socks' output).
>
> Am I right in thinking that all the classes which inherit from
> Perlbal::Socket have a max_idle_time of 0 and so never time out? So if
> someone did a TCP connect to perlbal client-facing port and then
> dropped off the net (so the socket never became readable after the
> connect), we'd leak an fd into state?
>
> Or is there another fd reaping mechanism apart from
> Perlbal::Socket::_do_cleanup? Or have I misunderstood the code (I'm
> looking at current svn here, r706).
Ah, thanks for reminding me of this - ran into it on another project last
week sometime.
This is a bug with Perlbal that's been in for the past ~2 months in the
trunk from changeset 692/693. It hasn't been released yet so as long as
you're using 1.59 or prior then you won't have this bug.
It's caused by the implementation of the persist_client_timeout service
tunable, a great idea but in the process the max_idle_time from
Perlbal::ClientHTTPBase was removed. The issue here is that
persist_client_timeout is defined per service, whereas max_idle_time was
specified for the class and Perlbal::Socket used it as such. Now that the
max_idle_time is gone, Perlbal::Socket always assumes 0 from the server
perspective.
Moving max_idle_time to read from the object reference itself might have
implications on the speed of the cleanup algorithm, which runs every 5
seconds and must be fast. Okay, so I just did revision 707... in some speed
tests, it runs about 20% slower than the previous version. This shouldn't
be a problem even for high volume sites, as it's cleanup code run every 5
seconds, not every main loop iteration. 
So - update to trunk again and give it a shot.
--
Mark Smith / xb95
smitty@gmail.com
| |
| John Berthels 2007-10-09, 1:12 pm |
| On 08/10/2007, Mark Smith <smitty@gmail.com> wrote:
> So - update to trunk again and give it a shot.
Yep, that's done the trick. Thanks very much.
jb
|
|
|
|
|