•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.
| [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
| [reply] [d/l] [select] |
|
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?
| [reply] |
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. | [reply] |
|
That will be a last resort for me.
| [reply] |
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. | [reply] |
|
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.
| [reply] |
|
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.
| [reply] |
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. | [reply] [d/l] |
|
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.
| [reply] |
|
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?
| [reply] |