Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

different versions of same Perl module in different Apache vhosts

by agaffney (Beadle)
on Jun 05, 2004 at 22:27 UTC ( [id://361695]=perlquestion: print w/replies, xml ) Need Help??

agaffney has asked for the wisdom of the Perl Monks concerning the following question:

I didn't really know where to post this since it isn't specifically Apache or Perl, so I'm posting here....just because :)

I run 2 vhosts under Apache 1.3.29 (needed for mod_perl-1.x which is needed by HTML::Mason) on my Gentoo server. One vhost is the current production site and the other vhost is the development version of the site. I use a custom Perl module for authentication and other common functions for all my Perl CGI/mod_perl scripts.

I want to be able to make changes to the module, but I only want it to affect the second vhost. Basically, I need to have 2 copies of my custom module, one for each vhost. Is there an easy way to do this?
  • Comment on different versions of same Perl module in different Apache vhosts

Replies are listed 'Best First'.
•Re: different versions of same Perl module in different Apache vhosts
by merlyn (Sage) on Jun 05, 2004 at 22:40 UTC
    No. There's only one mod_perl interpreter per child process, and you can't control which process gets each request. You'll need to run a separate swarm of Apache processes on a different listen port.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

Re: different versions of same Perl module in different Apache vhosts
by hv (Prior) on Jun 06, 2004 at 03:50 UTC

    I have exactly this problem, slightly bigger - currently 46 vhosts running between them 6 different versions of an application - and I've avoided mod_perl for now precisely because of the problem of multiple library versions. I understand that v2 mod_perl does/will fix this problem.

    Under v1 it might be possible to work around this problem if each module user knows (or can reach an object that knows) what version of each module it needs. It'd be a bit of a pain, but I can imagine replace each use My::Module; with $application->load_module('My::Module'), and (roughly):

    sub Application::load_module { my($self, $class) = @_; return 1 if do { no strict 'refs'; # may need string eq here ${"${class}::VERSION"} == $self->required_version($class); }; (my $path = "$class.pm") =~ s{::}{/}g; delete $INC{$path}; require $path; }

    It may also be possible to roll up something similar at a lower conceptual cost using Ingy's only.

    Hugo

      Unfortunately, I need a more transparent solution than either of those. Using 'only' might work if I can put a line in the vhost definition that restricts the version, instead of in the scripts. Is there a way to do that?
Re: different versions of same Perl module in different Apache vhosts
by water (Deacon) on Jun 06, 2004 at 01:43 UTC
    Run two apaches on the box, like merlyn said. (Actually, two swarms of apaches, but you get my drift.) Look carefully at your httpd.conf and vhosts.conf; factor out the common chunks, make tiny conf files for the small bits that differ by the two apaches (eg the listen port and perl path stuff), and and use includes on these various files to build up the final production.conf and dev.conf files. Believe me, you don't want to try and keep two sets of conf files in sync -- factor out the commonalities and you'll save time over the long run not having to chase down mysterious conf-related bugs.

    UPDATE: Another idea: consider moving dev to its own hardware. (Better, as then bad crashes or slowdowns don't harm production.) The dev machine can be very lightweight usually -- a semi-discarded whitebox a few years old running gentoo could very well be powerful enough for dev work and testing. So what if it can't handle load, or takes an extra second to respond -- its for development. With distinct hardware, you can use exactly the same conf files, directory structures, etc on dev and production, making change management, updates, and rollback much easier.

      That will be a last resort for me.
Re: different versions of same Perl module in different Apache vhosts
by perrin (Chancellor) on Jun 05, 2004 at 23:01 UTC
    You can use Apache::PerlVINC, although it may affect your performance. The recommended approach is to start two separate servers. You can use the same apache and just start it on two different ports with separate config files. Change @INC inside each one to point to the correct version of your modules.
      Would I need to use it in both vhost definitions? Could I just leave the primary alone and put the development module in some other dir and use Apache::PerlVINC with the development vhost definition? I can live with degraded performance on just the development site.
        I'm not sure about this, since I've never used Apache::PerlVINC. It seems like it should work, but would probably still affect performance in both. I think Apache::PerlVINC causes the modules to be re-compiled every time, which is a performance hit, and will ruin the copy-on-write shared memory that mod_perl would otherwise benefit from.
Re: different versions of same Perl module in different Apache vhosts
by BUU (Prior) on Jun 05, 2004 at 22:42 UTC
    Yes, just install it in to different directories and then use lib "/usr/lib/production" at the top of your production scrips, alteratively set the perl5lib enviroment variable someplace.
      Nope, this is a persistent Perl interpreter. Once it resolves a certain module it doesn't look again. So, whichever version of "My::Module" gets accessed first is the only that will ever get loaded.
        What if I were to use Apache::Reload in addition to modifiying @INC for the separate vhosts? Would mod_perl look for the specific file it loaded before or would it search through @INC for the module to check if it needs to be reloaded?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://361695]
Approved by exussum0
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (2)
As of 2024-04-19 19:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found