[mp1] PerlCleanupHandler in .htaccess file sometimes doesn't run
I've run into an interesting bug in mp1. If I have a PerlCleanupHandler
defined in a .htaccess file, then it won't run if there was a
PerlInitHandler defined in httpd.conf. It doesn't matter what the
PerlInitHandler does, as long as its there the cleanup fails. If I have
the init handler run from within the .htaccess, its all fine, and it
also works if I have a PerlLogHandler in .htaccess instead of a
PerlCleanupHandler.
I'll attach two test files. Foo.pm is loading via PerlModule in
httpd.conf, and I have |PerlInitHandler Foo-init|. I first noticed this
with Apache::Reload, but any init handler will do it.
With the init handler, I get lines in error_log for init, Request, and
cleanup1. Without, I get lines for Request, cleanup1, and then the die.
The cleanup1 handler was just for testing; removing it doesn't affect
the results.
I'm testing with RH9's perl 5.8.0, and cvs mod_perl/1.27_01-dev from
about 12 hours ago, with a self compiled apache_1.3.27. This also
happened with mp/1.27, but doesn't happen with mp2 (After I port my test
modules to mp2). mod_perl is built as a .so with
perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs
EVERYTHING=1
Thanks,
Bradley
PS Is there a way to subscribe to this list so that I can post, but not
receive any mails? I couldn't find a nomail option on the list page at
perl.apache.org. I've subscribed to the digest version for now.
package Foo;
use Apache;
sub init($$) : method {
warn init;
return Apache::OK;
}
sub cleanup($$) : method {
die XXX;
return Apache::OK;
}
1;
#!/usr/bin/perl -w
use lib qw(.);
use strict;
use warnings;
use Foo;
sub cleanup1 {
warn cleanup1;
return Apache::OK;
}
Apache-request-register_cleanup(\cleanup1);
Apache-request-send_http_header('text/plain');
warn Request;
print HI!;
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
#PerlInitHandler Foo-init
PerlCleanupHandler Foo-cleanup
Re: PerlCleanupHandler firing too early?
Trey Hyde wrote:
My PerlCleanupHandler seems to be firing before the content phase has
finished processing the page.
The handler pretty much looks like
sub handler {
my ($r) = @_;
undef $Foo::bar;
undef $Foo::baz;
return OK;
}
It's being invoked in a virtual host apache conf segment with
PerlCleanupHandler Apache::CleanupFoo
If I don't comment out the PerlCleanupHandler line pieces of the
application that rely on any variable that I undef in the Cleanup phase
will crash.
In the error log it doesn't _LOOK_ like the handler is being called
early. The log yields exactly what I would expect it to.
PID 1000 REWRITE CALLED initial: 1 main: 0
PID 1000 REWRITE CALLED initial: 0 main: 0
PID 1000 REWRITE CALLED initial: 0 main: 1
PID 1000 AUTHENTICATION CALLED
BUNCH OF PERL ERRORS GO HERE (can't call method foo on undefined value
and the like)
PID 1000 REWRITE CALLED initial:0 main: 1 (rewriting
/cgi-bin/error/error.pl)
PID 1000 LOGGER CALLED (uri: error.pl)
PID 1000 CLEANUP CALLED (uri: mod_perl app)
I'm running on Apache/1.3.27 (Unix) mod_perl/1.26 w/ embperl 1.3.6.
Does anyone have an idea of what is going on here (or what I'm doing
wrong here?). Am I right in thinking that the CleanupHandler isn't
supposed to have any effect on the code _running_ in the current or
subsequent processes? In summary, leave Cleanup handler in everything
that I undef in the cleanup handler gets undef'ed in the middle of
running the code, if I removed the CleanupHandler the app works as
intended.
In the current request the CleanupHandler happens the last. You can visually
see that using Apache::ShowRequest
http://search.cpan.org/author/DOUGM/Apache-Module-0.11/lib/Apache/ShowRequest.pm
However you don't show the code that you have the problem with, so certainly
we have no clue why does it fail. If your cleanup handler affects global
variable in the package, certainly you may have an impact on the subsequent
requests running in the same process.
If you still have this problem, reduce the problematic code to the very
minimum (2-3 lines of code?), so that the problem can be still reproduced and
post it here.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
PerlCleanupHandler firing too early?
My PerlCleanupHandler seems to be firing before the content phase has
finished processing the page.
The handler pretty much looks like
sub handler {
my ($r) = @_;
undef $Foo::bar;
undef $Foo::baz;
return OK;
}
It's being invoked in a virtual host apache conf segment with
PerlCleanupHandler Apache::CleanupFoo
If I don't comment out the PerlCleanupHandler line pieces of the
application that rely on any variable that I undef in the Cleanup phase
will crash.
In the error log it doesn't _LOOK_ like the handler is being called
early. The log yields exactly what I would expect it to.
PID 1000 REWRITE CALLED initial: 1 main: 0
PID 1000 REWRITE CALLED initial: 0 main: 0
PID 1000 REWRITE CALLED initial: 0 main: 1
PID 1000 AUTHENTICATION CALLED
BUNCH OF PERL ERRORS GO HERE (can't call method foo on undefined value
and the like)
PID 1000 REWRITE CALLED initial:0 main: 1 (rewriting
/cgi-bin/error/error.pl)
PID 1000 LOGGER CALLED (uri: error.pl)
PID 1000 CLEANUP CALLED (uri: mod_perl app)
I'm running on Apache/1.3.27 (Unix) mod_perl/1.26 w/ embperl 1.3.6.
Does anyone have an idea of what is going on here (or what I'm doing
wrong here?). Am I right in thinking that the CleanupHandler isn't
supposed to have any effect on the code _running_ in the current or
subsequent processes? In summary, leave Cleanup handler in everything
that I undef in the cleanup handler gets undef'ed in the middle of
running the code, if I removed the CleanupHandler the app works as
intended.
--
Richard Trey Hyde
Senior Software Engineer
CNET Channel
(949) 399 8722
[EMAIL PROTECTED]
http://www.cnetchannel.com
signature.asc
Description: This is a digitally signed message part
PerlCleanupHandler called from default-handler
I have written a Apache::DBILogger style log mechanism. It is enabled via the perl.conf in the Server context as: PerlCleanupHandler NC::LogHandler It works correctly, except for the fact that request handle by the default-handler do not call this handler. The mod_perl cookbook makes note that: ..a C module has to specifically want this processing to occur-it is not called automatically. How do I allow for this handler to be called on all requests? Note I also tried this as a PerlLogHandler to no avail. TIA, Tom Murphy
Re: PerlCleanupHandler called from default-handler
Tom Murphy wrote: I have written a Apache::DBILogger style log mechanism. It is enabled via the perl.conf in the Server context as: PerlCleanupHandler NC::LogHandler It works correctly, except for the fact that request handle by the default-handler do not call this handler. The mod_perl cookbook makes note that: ..a C module has to specifically want this processing to occur-it is not called automatically. well, what we said is true, but you're reading it the wrong way :) basically, all of the Perl*Handler directives - from PerlPostReadRequestHandler to PerlCleanupHandler - can be thought of as parts of the request cycle. however, this is true for all but the PerlCleanupHandler, which really isn't part of the request cycle - mod_perl just makes it look that way. what's really happening is that mod_perl is hooking your Perl handler into the per-request cleanup that Apache offers all C modules (mod_perl included). so it _should_ be called for every request it is configured to run for (should being highly caveated - people have reported that _sometimes_ this doesn't really happen). understanding that is A Good Thing. however, it's not going to help you very much here :) How do I allow for this handler to be called on all requests? Note I also tried this as a PerlLogHandler to no avail. if the PerlLogHandler doesn't get called then you probably have a configuration problem. both of these can exist on their own, outside of a container. something like PerlLogHandler NC::LogHandler Location foo ... if that doesn't show your log handler running then you need to check your error log for errors and make sure your handler compiles under perl -cw or something - if the log handler errors out, you really can't see it unless you look. of course, all this assumes that you built with EVERYTHING=1 - check Apache::Status to make sure. another thing you can try if that doesn't work out is compiling a debugging mod_perl (PERL_DEBUG=1 and PERL_TRACE=1 when building) and set PerlSetEnv MOD_PERL_TRACE on and watch the verbose output. HTH --Geoff
Invalid command 'PerlCleanupHandler'
Hi All,
On redhat 8 using mod_perl-1.99_05-3
I have the folloing in httpd.conf:
PerlCleanupHandler sub { %ENV = () }
in VirtualHost, and am getting:
Invalid command 'PerlCleanupHandler', perhaps mis-spelled or defined by a module not
included in the
server configuration
Not a problem with mod_perl 1.
Any help is appreciated.
Jie
Re: Invalid command 'PerlCleanupHandler'
Jie Gao wrote:
Hi All,
On redhat 8 using mod_perl-1.99_05-3
I have the folloing in httpd.conf:
PerlCleanupHandler sub { %ENV = () }
in VirtualHost, and am getting:
Invalid command 'PerlCleanupHandler', perhaps mis-spelled or defined by a module not
included in the
server configuration
Not a problem with mod_perl 1.
Any help is appreciated.
The documentation is pretty much trying to be up-to-date with the modperl cvs.
So if you use an old mod_perl release, it may not work as described. Update
your mod_perl to the current cvs and it'll work. See:
http://perl.apache.org/docs/2.0/user/install/install.html#Installing_mod_perl_from_Source
You need the 'CVS Bleeding-Edge Version' section
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello, Caught the problem. It was a unexpected 'print STDOUT' happening in the Cleanup Handler. :-( sorry for the trouble. regards srp You wrote: Envelope-to: [EMAIL PROTECTED] Received: from symonds.net [63.194.20.32] by symonds.net with smtp (Exim 3.35 #1 (Debian)) id 181QC0-0001uo-00; Tue, 15 Oct 2002 04:48:56 -0700 Date: Tue, 15 Oct 2002 04:48:56 -0700 (PDT) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler X-URL: http://www.symonds.net/ Message-Id: [EMAIL PROTECTED] From: [EMAIL PROTECTED] X-UIDL: HH\!TZ!!W[T!+/6!! Status: RO Thanks for reply .. Hello! internal_redirect() The required argument is an absolute URI path on the current server. The server will process the URI as if it were a whole new request, running the URI translation, MIME type checking, and other phases before invoking the appropriate content handler for the new URI. The content handler that eventually runs is not necessarily the same as the one that invoked internal_redirect(). This method should only be called within a content handler. Yes, I understand that. What I am saying is this ... After a successfull internal_redirect(), and return OK my content handler has exited - The content has now reached my client. Now my cleanup handler is executing. I am not understanding why Apache is attempting to write to client now !! Also, by using internal_redirect_handler() you can make r-handler (which is the current handler by default) handle this redirect(). ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED] regards srp
ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello, I have a mod_perl application which does a internal_redirect() and registers a cleanup handler before returning. I am noticing that the cleanup handler executes and i see the following in my log .. [Tue Oct 15 03:27:32 2002] [info] [client XYZ ] (9)Bad file number: client stopped connection before rvputs completed * Why is apache trying to write to client during the cleanup phase ? Further ... Since the call is to ap_rvputs(), I assumed it is not a mod_perl issue. I confirmed that the handler was 'default-handler' by asking ap_invoke_handler() to log each invocation. But when I forced the handler to be 'perl-script' by using internal_redirect_handler(). This time I get [Tue Oct 15 00:59:29 2002] [info] [client XYZ] (9)Bad file number: client stopped connection before rwrite completed I hacked ap_rvputs() ap_rwrite() to not return on a write() failure but to log the attempt. It seems that both want to write HTTP headers to client. ( I confirmed that it is for the same request 'r-the_request') Why is apache re-doing the request after a internal_redirect() ? ( and that too in the cleanup phase ??) Please help me understand this. Any hints most appreciated :-) regards srp ps :: please reply to me directly as i am not on the list
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello! internal_redirect() The required argument is an absolute URI path on the current server. The server will process the URI as if it were a whole new request, running the URI translation, MIME type checking, and other phases before invoking the appropriate content handler for the new URI. The content handler that eventually runs is not necessarily the same as the one that invoked internal_redirect(). This method should only be called within a content handler. That from Writing Apache modules with Perl and C. ssn Hello, ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED]
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello again. May be it helps to solve your problem. is_initial_req() There are several instances in which an incoming URI request can trigger one or more secondary internal requests. An internal request is triggered when internal_redirect() is called explicitly, and it also happens behind the scenes when lookup_file() and lookup_uri() are called. With the exception of the logging phase, which is run just once for the primary request, secondary requests are run through each of the transaction processing phases, and the appropriate handlers are called each time. There may be times when you don't want a particular handler running on a subrequest or internal redirect, either to avoid performance overhead or to avoid infinite recursion. The is_initial_req() method will return a true value if the current request is the primary one and false if the request is the result of a subrequest or an internal redirect. return DECLINED unless $r-is_initial_req; ssn Hello, ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED]
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Thanks for reply .. Hello! internal_redirect() The required argument is an absolute URI path on the current server. The server will process the URI as if it were a whole new request, running the URI translation, MIME type checking, and other phases before invoking the appropriate content handler for the new URI. The content handler that eventually runs is not necessarily the same as the one that invoked internal_redirect(). This method should only be called within a content handler. Yes, I understand that. What I am saying is this ... After a successfull internal_redirect(), and return OK my content handler has exited - The content has now reached my client. Now my cleanup handler is executing. I am not understanding why Apache is attempting to write to client now !! Also, by using internal_redirect_handler() you can make r-handler (which is the current handler by default) handle this redirect(). ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED] regards srp
Re: PerlCleanupHandler
On Fri, 11 Aug 2000, Tim Sweetman wrote: 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). this should be fixed with the hard_timeout - soft_timeout change. 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... right, because mod_perl runs Apache::Registry END blocks in a cleanup. 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. hmm, the hard_timeout() may have left Perl in a confused state. if you're still seeing this behavior with the soft_timeout() change, i'd appreciate any details you have on this.
Re: PerlCleanupHandler
On Wed, 9 Aug 2000, Michael Peppler wrote:
Hi,
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?
yes. but, the proper solution is for mod_perl to change usage of
hard_timeout() to soft_timeout(). hard_timeout() does a longjmp out to
the accept loop, whereas soft_timeout() just sets $r-connection-aborted
to 1, so all apache i/o calls become noops, but the script continues to
run until finished. i don't know why we used hard_timeout() in the first
place. if a script wants to abort, they'll need to do it themselves,
something along the lines of:
$r-print('foo');
die if $r-connection-aborted;
Index: Apache/Apache.pm
===
RCS file: /home/cvs/modperl/Apache/Apache.pm,v
retrieving revision 1.52
diff -u -r1.52 Apache.pm
--- Apache/Apache.pm2000/08/15 04:35:13 1.52
+++ Apache/Apache.pm2000/08/31 05:38:36
@@ -68,7 +68,7 @@
$_[1] ||= "";
#$_[1] = " " x $bufsiz unless defined $_[1]; #XXX?
-$r-hard_timeout("Apache-read");
+$r-soft_timeout("Apache-read");
while($bufsiz) {
$nrd = $r-read_client_block($buf, $bufsiz) || 0;
@@ -113,7 +113,7 @@
return 0;
}
-$r-hard_timeout("Apache-read");
+$r-soft_timeout("Apache-read");
while($bufsiz) {
$nrd = $r-get_client_block($buf, $bufsiz) || 0;
@@ -425,7 +425,7 @@
looping until it gets all of C$bytes_to_read or a timeout happens.
In addition, this method sets a timeout before reading with
-C$r-Egthard_timeout.
+C$r-Egtsoft_timeout.
=item $r-get_remote_host
@@ -909,7 +909,7 @@
=item $r-print( @list )
This method sends data to the client with C$r-Egtwrite_client, but first
-sets a timeout before sending with C$r-Egthard_timeout. This method is
+sets a timeout before sending with C$r-Egtsoft_timeout. This method is
called instead of CORE::print when you use print() in your mod_perl programs.
This method treats scalar references specially. If an item in @list is a
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.105
diff -u -r1.105 Apache.xs
--- src/modules/perl/Apache.xs 2000/08/31 03:39:45 1.105
+++ src/modules/perl/Apache.xs 2000/08/31 05:38:48
@@ -1033,7 +1033,7 @@
}
else {
CV *cv = GvCV(gv_fetchpv("Apache::write_client", FALSE, SVt_PVCV));
- hard_timeout("mod_perl: Apache-print", r);
+ soft_timeout("mod_perl: Apache-print", r);
PUSHMARK(mark);
#ifdef PERL_OBJECT
(void)(*CvXSUB(cv))(cv, pPerl); /* Apache::write_client; */
RE: push_handlers (was: PerlCleanupHandler vs register_cleanup)
a quick test showed the handlers to be FIFO, so I would expect you to get
moda
modb
modc
d
e
HTH
--Geoff
-Original Message-
From: Paul G. Weiss [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 2:38 PM
To: 'Stas Bekman'
Cc: modperl
Subject: push_handlers (was: PerlCleanupHandler vs register_cleanup)
While we're on the subject of handlers, if
I have
PerlLogHandlers moda modb modc
in my conf file
and I do
$r-push_handlers('PerlLogHandler', \d);
$r-push_handlers('PerlLogHandler', \e);
during the content phase
what is the order that the stacked log handlers run?
-P
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 12:47 PM
To: Paul G. Weiss
Cc: modperl
Subject: Re: PerlCleanupHandler vs register_cleanup
On Thu, 24 Aug 2000, Paul G. Weiss wrote:
What is the difference between doing
$r-push_handlers('PerlCleanupHandler', \function);
and
$r-register_cleanup(\function);
The same:
http://www.modperl.com/book/chapters/ch9.html#Server_Core_Functions
The register_cleanup() method registers a subroutine that
will be called
after the logging stage of a request. This is much the same
as installing
a cleanup handler with the PerlCleanupHandler directive. See
Chapter 7 for
some practical examples of using register_cleanup().
_
Stas Bekman JAm_pH -- Just Another
mod_perl Hacker
http://stason.org/ mod_perl Guide
http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: PerlCleanupHandler vs register_cleanup
On Thu, 24 Aug 2000, Paul G. Weiss wrote:
What is the difference between doing
$r-push_handlers('PerlCleanupHandler', \function);
and
$r-register_cleanup(\function);
The same:
http://www.modperl.com/book/chapters/ch9.html#Server_Core_Functions
The register_cleanup() method registers a subroutine that will be called
after the logging stage of a request. This is much the same as installing
a cleanup handler with the PerlCleanupHandler directive. See Chapter 7 for
some practical examples of using register_cleanup().
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
push_handlers (was: PerlCleanupHandler vs register_cleanup)
While we're on the subject of handlers, if
I have
PerlLogHandlers moda modb modc
in my conf file
and I do
$r-push_handlers('PerlLogHandler', \d);
$r-push_handlers('PerlLogHandler', \e);
during the content phase
what is the order that the stacked log handlers run?
-P
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 12:47 PM
To: Paul G. Weiss
Cc: modperl
Subject: Re: PerlCleanupHandler vs register_cleanup
On Thu, 24 Aug 2000, Paul G. Weiss wrote:
What is the difference between doing
$r-push_handlers('PerlCleanupHandler', \function);
and
$r-register_cleanup(\function);
The same:
http://www.modperl.com/book/chapters/ch9.html#Server_Core_Functions
The register_cleanup() method registers a subroutine that
will be called
after the logging stage of a request. This is much the same
as installing
a cleanup handler with the PerlCleanupHandler directive. See
Chapter 7 for
some practical examples of using register_cleanup().
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: PerlCleanupHandler
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!"
PerlCleanupHandler
Hi, 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... :-) Thanks! Michael -- Michael Peppler -||- Data Migrations Inc. [EMAIL PROTECTED]-||- http://www.mbay.net/~mpeppler Int. Sybase User Group -||- http://www.isug.com Sybase on Linux mailing list: [EMAIL PROTECTED]
