Re: When will PerlLogHandler *not* run

2000-08-21 Thread Rick Myers

On Aug 21, 2000 at 23:45:48 -0400, Paul G. Weiss twiddled the keys to say:
> 
> > Needless to say, I find that under certain conditions that I'm not
> > completely sure of, the loghandler doesn't run and the object does
> > get undef'ed (I know this from using perl-status and from the fact
> > that the process in question doesn't give me any timing statistics
> > from then on).  The question is, what combination of events could
> > cause the log handler not to run once I've pushed it, yet leave the
> > process intact to handle another request?
> > 
> > -Paul Weiss
> > 
>  
> 
> Whoops.  I meant to say "the loghandler doesn't run and the object
> *doesn't* get undef'ed."

This may or may not have any bearing on this question, but something
I've seen is that $r->register_cleanup() will stop responding sometimes.
After a while a whole pile of cleanups from one given child will just do
their thing one after another. I've always wondered why that is. Why
doesn't that child just hang instead of storing up all the registered
cleanups?

Rick Myers[EMAIL PROTECTED]

The Feynman Problem   1) Write down the problem.
Solving Algorithm 2) Think real hard.
  3) Write down the answer.



RE: When will PerlLogHandler *not* run

2000-08-21 Thread Paul G. Weiss


> Needless to say, I find that under certain conditions that I'm not
> completely sure of, the loghandler doesn't run and the object does
> get undef'ed (I know this from using perl-status and from the fact
> that the process in question doesn't give me any timing statistics
> from then on).  The question is, what combination of events could
> cause the log handler not to run once I've pushed it, yet leave the
> process intact to handle another request?
> 
> -Paul Weiss
> 
 

Whoops.  I meant to say "the loghandler doesn't run and the object
*doesn't* get undef'ed."

Sorry about that.

-P



When will PerlLogHandler *not* run

2000-08-21 Thread Paul G. Weiss

I have a timing module which is designed to only create a
single object.  It works according to the following pseudo-code

package TimeIt;

sub begin
{
my $this = get_object(shift);
my $op = shift;
# store start time in object
...
}

sub end
{
my $this = get_object(shift);
my $op = shift;
# store end time in object
...
}

sub output
{
my $this = get_object(shift);
# format timing info as a string
return $string;
}

# if method was called as a class method return the global
# object if it exists, otherwise create it
sub get_object
{
my $obj = shift;
return $obj if ref($obj);   # a real object
# $obj is class name
return $object if $object; # a global
$object = TimeIt->new;
Apache->push_handlers('PerlLogHandler', \&loghandler);
return $object;
}

sub loghandler
{
my $r = shift->last;
if ($object)
{
my $output = $object->output;  # generate output
$r->notes('TIMEITOUTPUT', $output);
  # the LogFormat uses %{TIMEITOUTPUT}n
undef $object;
}
return DECLINED;
}

The web page then uses it as follows:

TimeIt->begin('foo');
foo(@args);
TimeIt->end('foo');

for as many things as it wants to time.

Basically the log handler is responsible for resetting the object
so that the next request will create it again.  As you can see,
if the loghandler doesn't run, all is lost, because subsequent 
requests see $object already defined and don't recreate it.

Needless to say, I find that under certain conditions that I'm not
completely sure of, the loghandler doesn't run and the object does
get undef'ed (I know this from using perl-status and from the fact
that the process in question doesn't give me any timing statistics
from then on).  The question is, what combination of events could
cause the log handler not to run once I've pushed it, yet leave the
process intact to handle another request?

-Paul Weiss

P.S.  I know that the *real* way to fix this problem would be to use
an init handler to undef the object.  Unfortunately I don't have
complete control over the httpd.conf file ( a political rather than
a technical problem ) and so I'm trying to solve this problem using
Perl code alone.