On Sat, 3 Mar 2001, Brian Ferris wrote:
> I'm currently a developer for an on-line publication using Apache /
> mod_perl / Mason. We currently have about six developers working on the
> project and I have been running into problems with concurrent work on the
> Perl libraries that power our site.
>
> We use CVS to manage revisions, but the only way for a developer to see if
> their code is working is to run it on our webserver. However, mod_perl's
> very purpose is to keep one copy of your modules loaded from the
> start. StatINC addresses this problem to a certain extent, but it fails
> when you have multiple versions of a Perl module that you want to load
> depending on which user is requesting.
See Apache::PerlVINC
It's also covered in the guide
> I sort of got around this by modifying my Mason handler to examine the
> requested URI ( ex. /dev/user_name/blah.html ) and loading the appropriate
> module for that user. Basically, this involved modifying the @INC
> paths in the handler, requiring the modules, and then calling
> the StatINC handler sub to reload any modified modules. This sort
> of screams hack and it never worked that well. Processes would
> load the proper module for one user, and then use that same module
> to serve another user who was looking for his own modules. Chaos
> ensued...
>
> I have a few ideas as to what I should try next. Perhaps limiting
> RequestsPerChild to 1, such that libraries don't get reused? I don't know
> what the ramifications of this are.
>
> Short of running a webserver for each user (a bad solution in my
> opinion) does anyone have ideas?
>
> Thanks,
> Brian Ferris
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/