Re: handler($$) unreliability
On Sun, Jun 15, 2003 at 02:44:02PM +0800, Philippe M. Chiasson wrote:
[...]
This could be related to a recently discovered bug in
mp_preload_module(), see
http://marc.theaimsgroup.com/?t=10553271073r=1w=2
for the original report.
That is a possiblity. I am preloading Project::Control,
but I am not preloading other modules that inherit from
it. I am also using Apache::Reload, if that matters.
Below is how Project::Control is setup, which
is the module/handler that most commonly exhibits the
problem. Project::Control is a dispatcher that loads
(require-s) a module based on a URI to module name
mapping hash, then calls the run method in that
package. The require-d module is always a subclass
of Project::Control.pm. The failure becomes apparent
when the $apache-status call is made because
$apache is not an object in the failing case.
Again, this module almost always works. It usually
only begins failing after apache has been running
for several hours, and seems to be more common under
heavy load.
*** http.conf ***:
Files *.pcm
SetHandler perl-script
PerlModule Project::Control
PerlHandler Project::Control
/Files
*** library/Project/Control.pm ***:
package Project::Control;
use Apache();
use Apache::Constants qw(:common :response REDIRECT SERVER_ERROR);
use Apache::Reload;
use Class::MethodMaker
get_set = [ qw( apache ... ) ],
new_hash_init = '_create';
...
use vars qw/%URI_MAP/;
%URI_MAP = (
'/uri/one' = 'Project::Control::HandleUriOne',
... for different URIs
);
sub handler ($$) = {
my ($class, $apache) = @_;
Apache::request($apache);
$apache-status(200); # sets default *** Failure occurs here
...
my $self = $class-_create(apache = $apache, ...);
(my $uri = $apache-uri) =~ s/\.[^\.]+$//;
my $module = $URI_MAP{$uri} or Carp::confess(Page [$uri] not installed);
(my $path = $module) =~ s!::!/!g;
$path .= .pm;
bless $self, $module;
eval {
require $path;
$self-run( $apache );
};
...
return OK;
}
1;
*** library/Project/HandleUriOne ***:
package Project::HandleUriOne;
...
use Apache::Reload;
use base qw( Project::Control );
sub run {
my $self = shift;
... code to generate output goes here ...
}
1;
[Fri Jun 13 06:00:06 2003] [error] Can't call method status on an undefin=
ed
+value at Project/Control.pm line 116.
Does this happen only once per child, or does the affected child behaves
like that for each and every request to that handler?
It seems to happen for every request that the affected
child handles. I don't have a test case that exercises
the problem, so I don't have real solid data on the behavior,
but it seems like once a child begins exhibiting this
erroneous behavior, it continues to do so for the rest of
its lifetime. I am not sure whether it exhibits this
behavior from the time it is created or starts doing that
later after having successfully served other requests.
Any suggestions as to how to contruct a test case so that
I can make this problem be repeatable would be greatly
appreciated.
One thing that can fix this problem, if it's indeed caused by
mp_preload_module, would be to make sure to preload that module
with a PerlModule My::Class in your httpd.conf
I am preloading Project::Control, which I think would be
sufficient, but am not preloading the subclass modules that
it uses. I am not sure whether that matters or not.
sub handler is never overridden in the subclasses.
Thanks for your help.
--
Matthew Pressly
Re: handler($$) unreliability
On Sat, 2003-06-14 at 04:35, Matthew Pressly wrote:
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
This could be related to a recently discovered bug in
mp_preload_module(), see
http://marc.theaimsgroup.com/?t=10553271073r=1w=2
for the original report.
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
for a while, and usually under substantial load,
it appears that the handler in one child process starts
being called as if it did not have the prototype.
That is, $apache ($r) is in $_[0] instead of $_[1],
and I get messages like this:
[Fri Jun 13 06:00:06 2003] [error] Can't call method status on an undefin=
ed
+value at Project/Control.pm line 116.
Does this happen only once per child, or does the affected child behaves
like that for each and every request to that handler?
And things quit working because $apache is not set properly.
A server restart clears this up. This is a perl5.6.0
DSO build of mod_perl/apache (1.27), but I am fairly certain I
have also seen this occur on a static mod_perl/apache.
Any ideas on what causes this or a good way to track it down?
One thing that can fix this problem, if it's indeed caused by
mp_preload_module, would be to make sure to preload that module
with a PerlModule My::Class in your httpd.conf
--
Matthew Pressly
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$++redo}'
signature.asc
Description: This is a digitally signed message part
Re: handler($$) unreliability
Frank Maas wrote:
Are you using 'lookup_uri' or another form of subrequest somewhere
in your handlers? Try tracing your request and see where it goes
wrong. I had similar problems and it pointed out to be an error in
a subrequest. Consult the mailinglist archive if you want.
--Frank
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
Besides, you really, really want to move to perl 5.6.1.
__
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
handler($$) unreliability
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
for a while, and usually under substantial load,
it appears that the handler in one child process starts
being called as if it did not have the prototype.
That is, $apache ($r) is in $_[0] instead of $_[1],
and I get messages like this:
[Fri Jun 13 06:00:06 2003] [error] Can't call method status on an undefin=
ed
+value at Project/Control.pm line 116.
And things quit working because $apache is not set properly.
A server restart clears this up. This is a perl5.6.0
DSO build of mod_perl/apache (1.27), but I am fairly certain I
have also seen this occur on a static mod_perl/apache.
Any ideas on what causes this or a good way to track it down?
--
Matthew Pressly
RE: handler($$) unreliability
Are you using 'lookup_uri' or another form of subrequest somewhere
in your handlers? Try tracing your request and see where it goes
wrong. I had similar problems and it pointed out to be an error in
a subrequest. Consult the mailinglist archive if you want.
--Frank
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
...
