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";
> >
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:
f Engineer / Programmer
> http://www.arttoday.com/
> --
>
> - Original Message -
> From: "Aaron Johnson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, April 04, 2001 2:48 PM
> Subject: R
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 t
[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 r
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 is
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
p
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.co
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?
>
> Try Apache::SafeHang
> http://
On Mon, 17 Jan 2000, Bill Moseley 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 th
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.
> 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
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
13 matches
Mail list logo