Hello all,
Having some hard ( for me ) to track memory usage issues. We have moved
our production environment to a new machine with what we thought was
plenty of memory, but we seem to have an erratic bit of code somewhere
that eats all the available memory. We did not have this problem on our
In a private email someone mentioned that removing the \ before the $ might
make the messages more meaningful. That code was copy and pasted from the
current guide so if it should be $ and no \$ in front of UNIVERSAL then Stas
might want to know :^)
I changed it out and now it appears that it
[EMAIL PROTECTED] (Aaron Johnson) wrote:
In "the guide" it is recommended that a sub in the startup.pl file:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
}
You'll get more useful information if you get rid
/
--
- Original Message -
From: "Aaron Johnson" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 04, 2001 2:48 PM
Subject: Re: Run away processes
In a private email someone mentioned that removing the \ before the $
might
make the mes
ttoday.com/
--
- Original Message -
From: "Aaron Johnson" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 04, 2001 2:48 PM
Subject: Re: Run away processes
In a private email someone mentioned that removing the \ before the $
might
i think that it should be:
warn "\$class=$class can't \$UNIVERSAL::AUTOLOAD=$UNIVERSAL::AUTOLOAD!\n";
leads to less grepping and a quicker understanding of the problem.
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
Aaron Johnson wrote:
So should the entry in the Guide be rewritten to:
On Wed, 4 Apr 2001, Ken Williams wrote:
[EMAIL PROTECTED] (Aaron Johnson) wrote:
In "the guide" it is recommended that a sub in the startup.pl file:
sub UNIVERSAL::AUTOLOAD {
my $class = shift;
warn "$class can't \$UNIVERSAL::AUTOLOAD!\n";
}
On 20 Jan 2000, Greg Stark wrote:
Stas Bekman [EMAIL PROTECTED] writes:
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is this even
possible? Some type of watchdog, just like httpd.conf Timeout?
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
the client breaks the connection.
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is this even
possible? Some type of watchdog, just like
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
the client breaks the connection.
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is this even
possible? Some type of watchdog, just
At 06:48 PM 1/17/00 +0200, Stas Bekman wrote:
The httpd.conf Timeout setting doesn't effect mod_perl, it seems, even if
the client breaks the connection.
Is there a recommendation on how to catch stop run away mod_perl programs
in a way that's _not_ part of the run away program. Or is
11 matches
Mail list logo
