You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Erich L. Markert" <em...@pace.edu> on 2000/06/13 21:24:26 UTC
[OT] Making apps (un)available solution
I'm trying to figure out the best way to make apps (un)available without
having to edit the apache config files.
Any suggestions would be appreciated.
--
__________________________________________________________
Mr. Erich L. Markert emarkert@pace.edu
Computer Learning Center TEL (914)422-4328
Pace University
1 Martine Ave
White Plains, New York 10606-1932
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
Re: [OT] Making apps (un)available solution
Posted by Frank Wiles <fr...@wiles.org>.
.------[ Erich L. Markert wrote (2000/06/13 at 15:24:26) ]------
|
| I'm trying to figure out the best way to make apps (un)available without
| having to edit the apache config files.
|
| Any suggestions would be appreciated.
|
`-------------------------------------------------
I was discussing this just the other day with some fellow perl
coders. The only solution we can up with would be to either append
an Include with your configs in it. Or to store your config
information in a database or other flat file and use <Perl> sections
within the config.
Honestly I don't see any way around editing the config files short
of just using an Apache::Registry directory.
-------------------------------
Frank Wiles <fr...@wiles.org>
http://frank.wiles.org
-------------------------------
Re: limiting code that DProf profiles
Posted by Stas Bekman <st...@stason.org>.
On Mon, 19 Jun 2000, Chris Nokleberg wrote:
>
> I'm using Apache::DProf to profile a mod_perl script. The specific section
> I am looking to improve is hard to get meaningful numbers for, because in
> the DProf output it is overwhelmed by the time of child process startup
> and other things that I'm not interested. Is there a way to limit the code
> that DProf profiles? If not, any idea on how difficult it would be to
> patch?
It has nothing to do with DProf. You should tell dprofpp that analyzes
tmon.out to extract only specific data. I didn't try it but see:
man dprofpp:
-g subroutine
Ignore subroutines except subroutine and whatever is
called from it.
Hope this helps.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
limiting code that DProf profiles
Posted by Chris Nokleberg <cj...@rock.pickem.com>.
I'm using Apache::DProf to profile a mod_perl script. The specific section
I am looking to improve is hard to get meaningful numbers for, because in
the DProf output it is overwhelmed by the time of child process startup
and other things that I'm not interested. Is there a way to limit the code
that DProf profiles? If not, any idea on how difficult it would be to
patch?
Thanks,
Chris
Re: [OT] Making apps (un)available solution
Posted by Michael J Schout <ms...@gkg.net>.
On Mon, 19 Jun 2000, Matt Sergeant wrote:
> On Sun, 18 Jun 2000, Michael J Schout wrote:
>
> > On Tue, 13 Jun 2000, Erich L. Markert wrote:
> >
> > > I'm trying to figure out the best way to make apps (un)available without
> > > having to edit the apache config files.
> >
> > We did something like this by making a handler like this:
> >
> > package Foo::PerlHandler;
> >
> > use Class::MethodMaker
> > new_with_init => 'new',
> > get_set => [qw/request/];
> >
> > sub handler {
> > my ($class, $r) = @_;
>
> You forgot prototypes here, otherwise handler always gets called with just
> $r.
Yeah.. thats right.. the real one has prototypes. I should have just
cut/pasted it instead of reproducing it from memory :).
>
> > ($class, $r) = (__PACKAGE__, $class) unless defined $r;
> >
> > if (-f /tmp/foo.unavailable) {
> > $r->headers_out->add('Location', '/maintenance/index.html');
> > return REDIRECT;
> > }
> >
> > my $this = $class->new($r);
> > $this->service;
>
> You've also forgotten your exception handling code here. Always try and
> wrap your dispatch code in an eval:
Yes.. our production version also has this.. actually, we use Error.pm from
CPAN to catch a variety of exceptions... e.g.:
try {
$this->sevice;
} catch Error::Foo with {
# do something
} catch Error::Foo2 with {
# do something else
} otherwise {
# uncaught exception
};
But I didnt feel it was worth showing all of that in my original msg :).
Mike
Re: [OT] Making apps (un)available solution
Posted by Matt Sergeant <ma...@sergeant.org>.
On Sun, 18 Jun 2000, Michael J Schout wrote:
> On Tue, 13 Jun 2000, Erich L. Markert wrote:
>
> > I'm trying to figure out the best way to make apps (un)available without
> > having to edit the apache config files.
>
> We did something like this by making a handler like this:
>
> package Foo::PerlHandler;
>
> use Class::MethodMaker
> new_with_init => 'new',
> get_set => [qw/request/];
>
> sub handler {
> my ($class, $r) = @_;
You forgot prototypes here, otherwise handler always gets called with just
$r.
> ($class, $r) = (__PACKAGE__, $class) unless defined $r;
>
> if (-f /tmp/foo.unavailable) {
> $r->headers_out->add('Location', '/maintenance/index.html');
> return REDIRECT;
> }
>
> my $this = $class->new($r);
> $this->service;
You've also forgotten your exception handling code here. Always try and
wrap your dispatch code in an eval:
eval { $this->service; };
if ($@) {
# catch exceptions
}
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: [OT] Making apps (un)available solution
Posted by Michael J Schout <ms...@gkg.net>.
On Tue, 13 Jun 2000, Erich L. Markert wrote:
> I'm trying to figure out the best way to make apps (un)available without
> having to edit the apache config files.
We did something like this by making a handler like this:
package Foo::PerlHandler;
use Class::MethodMaker
new_with_init => 'new',
get_set => [qw/request/];
sub handler {
my ($class, $r) = @_;
($class, $r) = (__PACKAGE__, $class) unless defined $r;
if (-f /tmp/foo.unavailable) {
$r->headers_out->add('Location', '/maintenance/index.html');
return REDIRECT;
}
my $this = $class->new($r);
$this->service;
}
sub init {
my ($this, $r) = @_;
$this->request($r);
}
sub service {
die "service is virtual!\n";
}
__END__
Then in our actual apps, we inherit Foo::PerlHandler:
package Foo::MyApp;
use Foo::PerlHandler;
@ISA = qw(Foo::PerlHandler);
sub handler {
my ($class, $r) = @_;
($class, $r) = (__PACKAGE__, $class) unless defined $r;
# do pre-request things specific to Foo::MyApp
return $class->SUPER::handler($r);
}
sub service {
my ($this) = @_;
my $r = $this->request;
# do whatever here that you would do in your handler.
}
__END__
In httpd.conf:
<Location /foo/myapp>
SetHandler perl-script
PerlHandler Foo::MyApp
</Location>
In actuality, we usually dont have to even define a handler() in our
application classes because the one provided by Foo::PerlHandler does
everything we need. Occasionally it is useful to do overload it though (which
is why I show the simple example above.
The benefit of this is that as long as all of our applications make use of
Foo::PerlHandler as their parent class, then we can shut down all applications
and make them redirect to /maintenance/index.html by simply doing "touch
/tmp/foo.unavailable" on the web server(s). No need to restart, no need to
fiddle with config files.
To make the applications available again, just "rm /tmp/foo.unavailable" and
requests are not redirected to the maintenance page anymore.
Anyways, this is how we decided to deal with this issue. Theres lots of other
ways I am sure :).
Mike