Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Dev
Leaking files / file descriptors in HTTP::Body..
 

Index | Next | Previous | View Flat


bobtfish at bobtfish

Oct 6, 2008, 2:49 PM


Views: 643
Permalink
Leaking files / file descriptors in HTTP::Body..

Switching this to the dev list as it is a bit more involved.

On 6 Oct 2008, at 15:30, James R. Leu wrote:
>
<snip>
> ... or running out of file descriptors. Do a 'lsof -p <pid>' where
> PID
> is that of the httpd children. I see a file descriptor leak in
> Catalyst::Engine::finalize_body in my cat app.
>
> See this post for more info:
>
> http://lists.scsys.co.uk/pipermail/catalyst/2007-November/
> 015817.html

and to quote that:

> The contents of the
> files is the JSON data for the API calls I'm making from the
client back
> to the server. I've traced the origins of the files back to
Catalyst::Engine
> (more specifically HTTP::Body's use of File::Temp). If I add the
following
> 'hack' to the end of Catalyst::Engine::finalize_body the files in /
tmp
> get closed and I no longer experience the file handle exhaustion:
>
> if (defined($c->request->{_body})) {
> delete $c->request->{_body};
> }
>
>
> So I have a couple of questions:
> - is there a better way to 'fix' this?
> - has anyone else seen this?

I'm guessing from the above that you're also getting a
HTTP::Body::OctetStream object?

I've seen something similar to this. My processes don't appear to
leak file descriptors, but I _do_ leak temporary files (i.e. they
don't get cleaned up).

As this is happening for me, I thought I'd knock up some tests of the
unlink behavior (attached). They're not quite perfect yet, but a good
start at testing this specific case.

This test however steadfastly refuses to fail (on my laptop, haven't
tested at work yet), however if I alter the File::Temp->new call in
HTTP::Body::OctetStream to add UNLINK => 0, it fails as I'd expect
(so proving at least that it's testing what I think it is testing).

The only things I can think of which could be causing this are:
* Really old File::Temp versions (is UNLINK new behavior) - I'll
check this out when I get into work tomorrow.
* $File::Temp::KEEP_ALL = 1 - would it be sane to localise this
variable to 0 in HTTP::Body to stop users shooting themselves in the
foot?

Anyone else got any suggestions or ideas about what may be causing this?

Cheers
t0m
Attachments: put_octetstream_body_tempfile_test.diff (2.34 KB)

Subject User Time
Leaking files / file descriptors in HTTP::Body.. bobtfish at bobtfish Oct 6, 2008, 2:49 PM
    Re: Leaking files / file descriptors in HTTP::Body.. andy at hybridized Oct 6, 2008, 4:17 PM
    Re: Leaking files / file descriptors in HTTP::Body.. bobtfish at bobtfish Oct 7, 2008, 1:42 AM

  Index | Next | Previous | View Flat
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.