You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Matt Sergeant <ma...@sergeant.org> on 2007/09/24 19:37:48 UTC
[Fwd: Re: Apache::Reload crash patch]
FYI.
-------- Original Message --------
Subject: Re: Apache::Reload crash patch
Resent-Date: Mon, 24 Sep 2007 07:28:58 -0400
Resent-From: Liam Bryan <li...@richard-group.com>
Resent-To: matt@sergeant.org
Date: Mon, 23 Apr 2007 08:10:06 -0400
From: Liam Bryan <li...@richard-group.com>
To: Liam Bryan <li...@richard-group.com>
Matt:
I haven't heard back from you yet with regards to this aspect of
Apache::Reload. I was wondering if you had had a chance to review
it. Thanks!
On Mar 15, 2007, at 08:36, Liam Bryan wrote:
> Matt:
>
> At our company, we use the Apache::Reload module in most of our
> production installations, since we will often need to make
> adjustments without a restart of Apache. We manage multiple sites;
> and put site-specific customizations into separate .pm files. But,
> if one of these custom modules throws a compile error, then
> Apache::Reload will crash on line 158:
>
> Compilation failed in require at /Library/Perl/5.8.7/darwin-2level/
> Apache/Reload.pm line 158.
>
> Unfortunately, this error is thrown in Apache, and thus crashes
> every site we're managing, not just the specific customized site.
> We found that by wrapping the particular error with an eval{} and
> then trapping $@, we could prevent this error from cascading across
> all of our managed sites. Here's what we've customized it to be:
>
>
> eval {require $key;};
> warn("Apache::Reload: FAILED $package:\n\t$@") if $@;
>
> The eval{} does add some overhead, but a fairly negligible amount.
>
> If you'd like more detail, feel free to ask me. Thanks!
>
>
> Liam Bryan
> The Richard Group, Inc.
> liam@richard-group.com
> http://richard-group.com
> 703.584.5804
>
>
Liam Bryan
The Richard Group, Inc.
liam@richard-group.com
http://richard-group.com
703.584.5804
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Re: Apache::Reload crash patch]
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Hi Liam,
I've been hacking away on this and we will be releasing a new version of
Apache::Reload soonish. Sorry it has taken so long to get out the door,
I ran low on tuits and the workload was more than I expected to get the
A::R release separated from the mod_perl codebase.
I'll ping you when this goes out the door, thanks for your patience and
the patch.
- Fred
Matt Sergeant wrote:
> FYI.
>
> -------- Original Message --------
> Subject: Re: Apache::Reload crash patch
> Resent-Date: Mon, 24 Sep 2007 07:28:58 -0400
> Resent-From: Liam Bryan <li...@richard-group.com>
> Resent-To: matt@sergeant.org
> Date: Mon, 23 Apr 2007 08:10:06 -0400
> From: Liam Bryan <li...@richard-group.com>
> To: Liam Bryan <li...@richard-group.com>
>
> Matt:
>
> I haven't heard back from you yet with regards to this aspect of
> Apache::Reload. I was wondering if you had had a chance to review
> it. Thanks!
>
>
> On Mar 15, 2007, at 08:36, Liam Bryan wrote:
>
>> Matt:
>>
>> At our company, we use the Apache::Reload module in most of our
>> production installations, since we will often need to make
>> adjustments without a restart of Apache. We manage multiple sites;
>> and put site-specific customizations into separate .pm files. But,
>> if one of these custom modules throws a compile error, then
>> Apache::Reload will crash on line 158:
>>
>> Compilation failed in require at /Library/Perl/5.8.7/darwin-2level/
>> Apache/Reload.pm line 158.
>>
>> Unfortunately, this error is thrown in Apache, and thus crashes every
>> site we're managing, not just the specific customized site. We found
>> that by wrapping the particular error with an eval{} and then
>> trapping $@, we could prevent this error from cascading across all of
>> our managed sites. Here's what we've customized it to be:
>>
>>
>> eval {require $key;};
>> warn("Apache::Reload: FAILED $package:\n\t$@") if $@;
>>
>> The eval{} does add some overhead, but a fairly negligible amount.
>>
>> If you'd like more detail, feel free to ask me. Thanks!
>>
>>
>> Liam Bryan
>> The Richard Group, Inc.
>> liam@richard-group.com
>> http://richard-group.com
>> 703.584.5804
>>
>>
>
> Liam Bryan
> The Richard Group, Inc.
> liam@richard-group.com
> http://richard-group.com
> 703.584.5804
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Fwd: Re: Apache::Reload crash patch]
Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
Matt Sergeant wrote:
> FYI.
Sorry - I haven't been moving as fast on this as I've wanted to. I've
been having to deal with some family commitments that have eaten up most
of my weekend coding time and at least a day a week for the past few months.
My goal is to get this mostly done by ApacheCon in about six weeks.
I've been banging my head against some of the Apache::Test stuff but I'm
confident that I can get it released by then.
If anyone has a bucket of tuits and can lend a hand, please feel free to
jump in and help out :) To do this we'll need an Apache::Test release
in addition to the Apache::Reload release because of the SameInterp
refactoring. A modperl core release isn't necessary, but may be desirable.
Thoughts?
- Fred
>
> -------- Original Message --------
> Subject: Re: Apache::Reload crash patch
> Resent-Date: Mon, 24 Sep 2007 07:28:58 -0400
> Resent-From: Liam Bryan <li...@richard-group.com>
> Resent-To: matt@sergeant.org
> Date: Mon, 23 Apr 2007 08:10:06 -0400
> From: Liam Bryan <li...@richard-group.com>
> To: Liam Bryan <li...@richard-group.com>
>
> Matt:
>
> I haven't heard back from you yet with regards to this aspect of
> Apache::Reload. I was wondering if you had had a chance to review
> it. Thanks!
>
>
> On Mar 15, 2007, at 08:36, Liam Bryan wrote:
>
>> Matt:
>>
>> At our company, we use the Apache::Reload module in most of our
>> production installations, since we will often need to make
>> adjustments without a restart of Apache. We manage multiple sites;
>> and put site-specific customizations into separate .pm files. But,
>> if one of these custom modules throws a compile error, then
>> Apache::Reload will crash on line 158:
>>
>> Compilation failed in require at /Library/Perl/5.8.7/darwin-2level/
>> Apache/Reload.pm line 158.
>>
>> Unfortunately, this error is thrown in Apache, and thus crashes every
>> site we're managing, not just the specific customized site. We found
>> that by wrapping the particular error with an eval{} and then
>> trapping $@, we could prevent this error from cascading across all of
>> our managed sites. Here's what we've customized it to be:
>>
>>
>> eval {require $key;};
>> warn("Apache::Reload: FAILED $package:\n\t$@") if $@;
>>
>> The eval{} does add some overhead, but a fairly negligible amount.
>>
>> If you'd like more detail, feel free to ask me. Thanks!
>>
>>
>> Liam Bryan
>> The Richard Group, Inc.
>> liam@richard-group.com
>> http://richard-group.com
>> 703.584.5804
>>
>>
>
> Liam Bryan
> The Richard Group, Inc.
> liam@richard-group.com
> http://richard-group.com
> 703.584.5804
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org