Hi,
Michael Peppler wrote:
> We're seeing a number of requests where the write from apache to the
> client browser times out and the SIGALRM signal fires. Our
> Apache::Registry scripts in that case don't clean up correctly,
> leaving session lock files around, which of course causes that
> particular session to be screwed up for a while.
>
> My question is would a Cleanup handler still be called in this case?
>
> ( I'm asking because it's a large site, and I can't just add code left
> and right... :-)
I've seen something similar - when the client browser times out,
execution seems to stop mid-Print statement, and mod_Perl gets ready for
the next request, without cleaning up objects present (or, at least,
without calling ->DESTROY).
IIRC, "END" blocks are called by mod_Perl, rather than Perl itself,
since Perl normally calls them only when the interpreter is about to
shut down. END blocks still get called in this situation, so if you run
foo.pl and manage to hit stop before it's printed its output...
my $object = new Foo::Bar;
# blah blah blah
print "The answer is ", $object->answer;
sub END { warn "bye!\n" };
and in Bar.pm
sub DESTROY { warn "outta here!\n" };
... you get "bye!" in the error log, but not "outta here!".
This obviously plays merry hell with database handles on transactioned
databases, session locks, etc.
I don't know for sure if SIGALRM is involved in this, though that seems
plausible.
My guess is that if END gets called, so will a cleanup handler.
More disturbingly, there seem to be very occasional cases where the
cleanup stuff doesn't do what's expected of it, so I suggest you keep an
eye on what's happening. Our current workaround - not a good one - is to
kill $$ when objects don't get cleaned up correctly.
Hope this helps...
--
Tim Sweetman
A L Digital
"When in Rome, burn it!"
