SPUG: Newbie mod_perl q: When modules are loaded

Dan Sanderson spug at dansanderson.com
Sat May 8 01:37:31 CDT 2004

Incidentally, stopping and starting Apache does fix the Changes problem,
my questions are more about the expected development workflow for mod_perl
websites.  If there's a well-known explanation, or good troubleshooting
steps for modules that can't be found, I'd be interested in that as well.

-- Dan

On Fri, 7 May 2004, Dan Sanderson wrote:

> Hi all -
> I'm getting started with mod_perl on a toy server I own.  (I have root and
> can modify Apache configuration, and can restart the web server.)  It's
> running Debian 3.0r2 stable, and I'm keeping it that way, which means I'm
> using Apache 1.3.26 and mod_perl 1.26.  I'm starting out with trying to
> use Apache::Registry to speed up regular Perl CGI scripts.
> I understand that mod_perl compiles and caches scripts and modules once on
> first load, and uses the cached versions on subsequent loads.  A default
> configuration knows to recompile scripts when they change, but not
> modules.  At the cost of performance, the following Apache configuration
> line would also check modules for updates before loading the cached
> versions:
>  PerlInitHandler Apache::StatINC
> When I tried this, I noticed that my apps (specifically Kwiki) would
> complain about missing modules about half the time.  Always, a reload of
> the page would succeed.
> When I removed the line, most of the original behavior was restored,
> except one of the modules is permanently unavailable.  The error says
> "Can't locate CGI/Kwiki/Changes.pm in @INC (@INC contains: ...)", where
> the paths definitely do not contain the module.  The app normally finds
> the module using a "use lib" line to the path to the libraries in the CGI
> script, and it does this successfully for other parts of the Kwiki.  The
> use lib path is not in the list of paths in the error message.
> Kwiki's index.cgi loads modules by name from its configuration file:
> changes_class is set to "CGI::Kwiki::Changes".  Would this cause a
> specific problem for mod_perl, with or without the StatINC configuration?
> Given that mod_perl doesn't reload modules with a high performance
> configuration, what's the best way to refresh the cache when new modules
> are deployed (presumably from a test instance to a production instance)?
> Is there a better way to configure a development instance of a mod_perl
> website to reload modules when they change, than StatINC?  The docs
> tentatively suggest a couple of other options, but I get the impression
> there is no official recommendation.  Is that about right?
> Is mod_perl 2 better at this?
> Thanks for any advice you can provide!
> -- Dan
> _____________________________________________________________
> Seattle Perl Users Group Mailing List
> POST TO: spug-list at mail.pm.org  http://spugwiki.perlocity.org
> ACCOUNT CONFIG: http://mail.pm.org/mailman/listinfo/spug-list
> MEETINGS: 3rd Tuesdays, Location Unknown
> WEB PAGE: http://www.seattleperl.org

More information about the spug-list mailing list