Hi, > we're looking for a way to offer version handling to our serverside perl > app.
You'll find many discussions of this in the mailing archive with multiple options. > My first ideas goes as: > > <Location /myApp-v2.0.0/> > PerlSwitches -I /some/path/v2.0.0/ > PerlResponseHandler run > </Location> > > <Location /myApp-v2.0.1/> > PerlSwitches -I /some/path/v2.0.1/ > PerlResponseHandler run > </Location> That won't work. Those use the same perl interpreter and it can't load multiple versions of the same module. > Alt. solutions are rename each package to be version unique. That will work. You can also run separate mod_perl backends, or you can create additional interpreters with this: http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ Keep in mind, that will make your processes grow considerably. > * we use worker mpm for memory sharing. What do you mean by memory sharing? Shared variables? FYI, worker normally uses more memory than prefork on unix systems because of copy-on-write. > * 100+ versions of the app is quite likely to exist before dropping the > backend. > will make it 100x the initial apps memory. Could this be an apache > performance issue? It will certainly use a lot of RAM, so make sure you have it. > * to lanch a new version i prefer to not alter the apache config constantly > is there a way to make this dynamically? There's all kind of conf manipulation stuff in mod_perl. I don't use any of it, so I'll leave that to someone else. I prefer to use templates to generate the conf files, so they're easier to see and debug. - Perrin
