Sophie

Sophie

distrib > Mandriva > 9.1 > ppc > by-pkgid > 171d3e449a0149039f39302768e6c3c2 > files > 236

apache2-mod_perl-2.0.44_1.99_08-3mdk.ppc.rpm

=head1 NAME

Apache::Reload - Reload Perl Modules when Changed on Disk

=head1 Synopsis

  # Monitor and reload all modules in %INC:
  # httpd.conf:
  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload

  # Reload groups of modules:
  # httpd.conf:
  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload
  PerlSetVar ReloadAll Off
  PerlSetVar ReloadModules "ModPerl::* Apache::*"
  #PerlSetVar ReloadDebug On

  # Reload a single module from within itself:
  package My::Apache::Module;
  use Apache::Reload;
  sub handler { ... }
  1;

=head1 Description

C<Apache::Reload> reloads modules that change on the disk.

When Perl pulls a file via C<require>, it stores the filename in the
global hash C<%INC>.  The next time Perl tries to C<require> the same
file, it sees the file in C<%INC> and does not reload from disk.  This
module's handler can be configured to iterate over the modules in
C<%INC> and reload those that have changed on disk or only specific
modules that have registered themselves with C<Apache::Reload>. It can
also do the check for modified modules, when a special touch-file has
been modified.

Note that C<Apache::Reload> operates on the current context of
C<@INC>.  Which means, when called as a C<Perl*Handler> it will not
see C<@INC> paths added or removed by C<Apache::Registry> scripts, as
the value of C<@INC> is saved on server startup and restored to that
value after each request.  In other words, if you want
C<Apache::Reload> to work with modules that live in custom C<@INC>
paths, you should modify C<@INC> when the server is started.  Besides,
C<'use lib'> in the startup script, you can also set the C<PERL5LIB>
variable in the httpd's environment to include any non-standard 'lib'
directories that you choose.  For example, to accomplish that you can
include a line:

  PERL5LIB=/home/httpd/perl/extra; export PERL5LIB

in the script that starts Apache. Alternatively, you can set this
environment variable in I<httpd.conf>:

  PerlSetEnv PERL5LIB /home/httpd/perl/extra

=head2 Monitor All Modules in C<%INC>

To monitor and reload all modules in C<%INC>, simply add the following
configuration to your I<httpd.conf>:

  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload

=head2 Register Modules Implicitly

To only reload modules that have registered with C<Apache::Reload>,
add the following to the I<httpd.conf>:

  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload
  PerlSetVar ReloadAll Off
  # ReloadAll defaults to On

Then any modules with the line:

  use Apache::Reload;

Will be reloaded when they change.

=head2 Register Modules Explicitly

You can also register modules explicitly in your I<httpd.conf> file
that you want to be reloaded on change:

  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload
  PerlSetVar ReloadAll Off
  PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::Test"

Note that these are split on whitespace, but the module list B<must>
be in quotes, otherwise Apache tries to parse the parameter list.

The C<*> wild character can be used to register groups of files under
the same namespace. For example the setting:

  PerlSetVar ReloadModules "ModPerl::* Apache::*"

will monitor all modules under the namespaces C<ModPerl::> and
C<Apache::>.

=head2 Monitor Only Certain Sub Directories

To reload modules only in certain directories (and their
subdirectories) add the following to the I<httpd.conf>:

  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload
  PerlSetVar ReloadDirectories "/tmp/project1 /tmp/project2"

You can further narrow the list of modules to be reloaded from the
chosen directories with C<ReloadModules> as in:

  PerlModule Apache::Reload
  PerlInitHandler Apache::Reload
  PerlSetVar ReloadDirectories "/tmp/project1 /tmp/project2"
  PerlSetVar ReloadAll Off
  PerlSetVar ReloadModules "MyApache::*"

In this configuration example only modules from the namespace
C<MyApache::> found in the directories I</tmp/project1/> and
I</tmp/project2/> (and their subdirectories) will be reloaded.

=head2 Special "Touch" File

You can also declare a file, which when gets C<touch(1)>ed, causes the
reloads to be performed. For example if you set:

  PerlSetVar ReloadTouchFile /tmp/reload_modules

and don't C<touch(1)> the file I</tmp/reload_modules>, the reloads
won't happen until you go to the command line and type:

  % touch /tmp/reload_modules

When you do that, the modules that have been changed, will be
magically reloaded on the next request. This option works with any
mode described before.

=head1 Performance Issues

This modules is perfectly suited for a development environment. Though
it's possible that you would like to use it in a production
environment, since with C<Apache::Reload> you don't have to restart
the server in order to reload changed modules during software
updates. Though this convenience comes at a price:

=over

=item *

If the "touch" file feature is used, C<Apache::Reload> has to stat(2)
the touch file on each request, which adds a slight but most likely
insignificant overhead to response times. Otherwise C<Apache::Reload>
will stat(2) each registered module or even worse--all modules in
C<%INC>, which will significantly slow everything down.

=item *

Once the child process reloads the modules, the memory used by these
modules is not shared with the parent process anymore. Therefore the
memory consumption may grow significantly.

=back

Therefore doing a full server stop and restart is probably a better
solution.

=head1 Debug

If you aren't sure whether the modules that are supposed to be
reloaded, are actually getting reloaded, turn the debug mode on:

  PerlSetVar ReloadDebug On

=head1 Problems With Reloading Modules Which Do Not Declare Their Package Name

If you modify modules which don't declare their C<package> and rely on
C<Apache::Reload> to reload them you may encounter problems: i.e.,
it'll appear as if the module wasn't reloaded when in fact it
was. This happens because when C<Apache::Reload> C<require()>s such a
module all the global symbols end up in the C<Apache::Reload>
namespace!  So the module does get reloaded and you see the compile
time errors if there are any, but the symbols don't get imported to
the right namespace. Therefore the old version of the code is running.

=head1 Threaded MPM and Multiple Perl Interpreters

If you use C<Apache::Reload> with a threaded MPM and multiple Perl
interpreters, the modules will be reloaded by each interpreter as they
are used, not every interpreters at once.  Similar to mod_perl 1.0
where each child has its own Perl interpreter, the modules are
reloaded as each child is hit with a request.

If a module is loaded at startup, the syntax tree of each subroutine
is shared between interpreters (big win), but each subroutine has its
own padlist (where lexical my variables are stored).  Once
C<Apache::Reload> reloads a module, this sharing goes away and each
Perl interpreter will have its own copy of the syntax tree for the
reloaded subroutines.


=head1 Pseudo-hashes

The short summary of this is: Don't use pseudo-hashes. They are
deprecated since Perl 5.8 and are removed in 5.9.

Use an array with constant indexes. Its faster in the general case,
its more guaranteed, and generally, it works.

The long summary is that some work has been done to get this module
working with modules that use pseudo-hashes, but it's still broken in
the case of a single module that contains multiple packages that all
use pseudo-hashes.

So don't do that.

=head1 Authors

Matt Sergeant, matt@sergeant.org

Stas Bekman (porting to mod_perl 2.0)

A few concepts borrowed from C<Stonehenge::Reload> by Randal Schwartz
and C<Apache::StatINC> (mod_perl 1.x) by Doug MacEachern and Ask
Bjoern Hansen.

=head1 See Also

C<Stonehenge::Reload>

=cut