How to report problems with modperl 2.0

[Stas Bekman <st...@stason.org>]

At this time some people will try to run incorrect versions of Apache 
and mod_perl and this will cause to most of your problems. So before we 
attempt to answer your questions, you have to tell us what versions you 
were using. Therefore:

Whenever you have a problem, first run:

   t/REPORT > report

which generates all the info that we need.
Now add the description of the problem where it says so, add a coredump 
if relevant where it says so and send it here with a nice descriptive 
subject.

Also remember that Apache 2.0 and mod_perl 2.0 weren't released yet and 
things change. So if you want to try building things, you must use the 
*released* mod_perl 1.99 with *released* Apache 2.0.35 and not mixing up 
with cvs versions. This will save you a lot of trouble.

Also whenever you have problems with interfaces grep for examples in the 
t/ directory. There are many tests there, which exercise most of the 
mod_perl 2.0. Chances are that if you look there, you will find your 
problem solved already.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: "Kind-of" PerlSections, and location question

[Perrin Harkins <pe...@elem.com>]

Daniel W. Burke wrote:
> We have an application we're serving by using the same
> set of source code, and setting up different <Location>
> sections in the virtual host to set different variables
> and path aliases based on who the customer is...
...
> What I'd like to do (if even possible!), is have something
> like this:
> 
> Have a databae table that stores the information for each
> setting, then load it dynamically as a request comes in...

Off the top of my head, there are two simple ways to do this.  The first 
is to generate your httpd.conf using a template and database.  I've done 
this using Template Toolkit, and it worked great.  This also works for 
servers that don't have mod_perl, like proxy servers.

The other way would be to write a PerlTransHandler to look at all 
incoming requests and then decide how to handle them based on your 
database info.  This is better if you need to be able to update it 
without restarting apache.

- Perrin

Re: "Kind-of" PerlSections, and location question

[Geoffrey Young <ge...@modperlcookbook.org>]

> 
> what I'm hoping to be able to do should only have to load the
> settings once (the first time a request comes in for that location)
> for each process, so I'm not too concerned about database access..
> 
> The main question I need answered first is, is this even possible?


IIRC, Jay Lawrence was playing with this exact thing just a few months 
ago, but I don't know how it turned out.  you might want to ping him 
about it privately if he doesn't catch this thread.

HTH

--Geoff

Re: "Kind-of" PerlSections, and location question

["Daniel W. Burke" <db...@comcast.net>]

On Mon, 15 Apr 2002, Steven Lembark wrote:

> > Have a databae table that stores the information for each
> > setting, then load it dynamically as a request comes in...
> > mailer dream code:
> >
> > $ENV{REQUEST_URI} =~ /^\/(.*?)\//;
> > $base_path = $1;
> > if (!exists($Location{$base_path})) {
> > 	... do database calls to load necessairy information
> > 	... and set as if this was a perl section in an
> > 	... httpd.conf file.
> > }
> >
> > ... then execute as if that location section was always there
> >
>
> Timestamping the database entry for the site might also
> help, since you wouldn't have to re-load the entire thing
> every time the site was hit.
>

what I'm hoping to be able to do should only have to load the
settings once (the first time a request comes in for that location)
for each process, so I'm not too concerned about database access..

The main question I need answered first is, is this even possible?

Dan.

Re: "Kind-of" PerlSections, and location question

[Steven Lembark <le...@wrkhors.com>]

> Have a databae table that stores the information for each
> setting, then load it dynamically as a request comes in...
> mailer dream code:
>
> $ENV{REQUEST_URI} =~ /^\/(.*?)\//;
> $base_path = $1;
> if (!exists($Location{$base_path})) {
> 	... do database calls to load necessairy information
> 	... and set as if this was a perl section in an
> 	... httpd.conf file.
> }
>
> ... then execute as if that location section was always there
>
> If there's a better solution then this, I'm also eager to
> hear it :)

Depending on the rate of server additions you might be
better off loading these at startup time or on a user
signal (e.g., $SIG{USR1} = \&reload_stuff_from_db).

Timestamping the database entry for the site might also
help, since you wouldn't have to re-load the entire thing
every time the site was hit.

--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 800 762 1582

"Kind-of" PerlSections, and location question

["Daniel W. Burke" <db...@comcast.net>]

I'm wondering if this is possible at all, and if so, how
to accomplish it...

We have an application we're serving by using the same
set of source code, and setting up different <Location>
sections in the virtual host to set different variables
and path aliases based on who the customer is...

But we have clusters of 6 servers in multiple locations,
with more such setups to come, and with the rate of having
to add sites because of new customers and temp sites for
sales demos, it's becoming difficult to manage so many
setups in this fashon, and restarting apache becomes more
and more an unpleasant thing to do with the more end-users
that are hitting it.

What I'd like to do (if even possible!), is have something
like this:

Have a databae table that stores the information for each
setting, then load it dynamically as a request comes in...
mailer dream code:

$ENV{REQUEST_URI} =~ /^\/(.*?)\//;
$base_path = $1;
if (!exists($Location{$base_path})) {
	... do database calls to load necessairy information
	... and set as if this was a perl section in an
	... httpd.conf file.
}

... then execute as if that location section was always there

If there's a better solution then this, I'm also eager to
hear it :)

Dan.

Re: How to report problems with modperl 2.0

[Stas Bekman <st...@stason.org>]

Stas Bekman wrote:
> At this time some people will try to run incorrect versions of Apache 
> and mod_perl and this will cause to most of your problems. So before we 
> attempt to answer your questions, you have to tell us what versions you 
> were using. Therefore:
> 
> Whenever you have a problem, first run:
> 
>   t/REPORT > report
> 
> which generates all the info that we need.
> Now add the description of the problem where it says so, add a coredump 
> if relevant where it says so and send it here with a nice descriptive 
> subject.
> 
> Also remember that Apache 2.0 and mod_perl 2.0 weren't released yet and 
> things change. So if you want to try building things, you must use the 
> *released* mod_perl 1.99 with *released* Apache 2.0.35 and not mixing up 
> with cvs versions. This will save you a lot of trouble.
> 
> Also whenever you have problems with interfaces grep for examples in the 
> t/ directory. There are many tests there, which exercise most of the 
> mod_perl 2.0. Chances are that if you look there, you will find your 
> problem solved already.

I've put some of this info online

http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/help/help.html#Reporting_Problems

-- 


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com