max_idle_time of zero - leaked fds?

Mark Smith smitty at
Mon Oct 8 18:13:28 UTC 2007

> 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

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 at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the perlbal mailing list