Yes, reverse proxies are king :) On my hosting servers I have a light proxy fronting 3 modperl servers on a single box (with a total of about 100 vhosts) and one tomcat server(on the same box, haha). Its a pretty nice configuration that really has done us well over the last 5+ years.
As far as my java app, its not that modperl could -not- do it, but when we are selling hundreds of shrinkwrapped units a month modperl becomes quickly unsupportable for me, there are just too many variables once it gets into the field. Where does that module go, whats that path to it, is there a version conflict, what stupid thing did microsoft do now(we deploy on windows) etc etc etc. With the Java I can install tomcat, drop in a new server.xml and plop in a .war file. HUP the server and I have a locally installed system that only phones home for registration and serialization purposes. If it doesnt find the signature in the conf file it knows its a local machine, not a public server, so its feature set reduces. That gives me a 100% identical codebase in a single account/single box local server and the public server that consists of four machines and hundreds or thousands of accounts. That ability to say 'this is my app, make it run now' is the real attraction. Not being able to grok the source is a requirement as well. Additionally, I can go multi-platform with just a new install tool since everything works out of the box without compiling. It really is incredibly seamless and after more years modperling then I can count I've never been able to get it that clean in deployment. Like I said, nothing you can't DO with modperl but its just a lot HARDER to do it and there are enough dragons to slay, no need to add more to the mix. John- ----- Original Message Follows ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Why people not using mod_perl Date: Tue, 30 Nov 2004 23:50:55 +0000 > In many casee, the hard part to deploy mod_perl > application seem due to the huge memory usage. But this > can be solved by using the dual (light+modperl) setup. The > dual setup has also another advantage: it allows virtual > hosting users to run his own standalone Apache at a given > port (have the light server to proxy to that port.) > The virtual host user still needs to restart his > mod_perl if program changes, but the light server does not > , and so the other users won't be affected. > > The example you mentioned about using Java over Perl > looks interesting. Can you be more specific, since > we rarely hear cases where Perl can't do but Java. :-) > > > siberian wrote: > > Tue, 30 Nov 2004 15:00:45 -0800 > > <don flamesuit> > > One thing people don't talk about much is deployability. > I've had to start moving away from ModPerl in some > situations for just this reason. > > For example, my recent projects revolve around a public > server that everyone can use with the option to install a > local server on their network that delivers the same > functionality (same codebase with some some tweaks based > on its configuration status). The install has to go > smoothly every single time on a variety of platforms. > > Originally I tried to get modperl up in this environment > and it really just was tough., module dependancies, things > like that. Additionally, and I know this is not cool to > say, I didn't really want the entire codebase sitting on > someone's machine since its a shrinkwrap product in a > highly competitive space. Yea yea, you can reverse compile > java classes etc etc etc, its just not the same as 'open > the .pm file'. > > So that lead to java (Tomcat+Struts) which pretty quickly > and easily gave me a single package deployment method, no > source included and with no dependancies to speak of. Its > literally a double-click installer and a reboot(just to be > cautious, not really required) and the entire system is up > and running with a reverse proxy, tomcat, struts and all > our apps. > > I know I could have accomplished this with modperl but > having done many modperl install packages in the past I > know its just not as easy and not nearly as bulletproof. > > I still use a lot of modperl (South African Airways > Holidays etc) but whenever deployability is a key feature > I've moved to Java. Its not so bad once you get used to > doing things in longhand ;) > > Solve the deployability issue and I'd jump back in a > heartbeat on those projects. A better way to package > dependancies up, obsfuscated source etc. > </remove flamesuit> > > John, still loving my modperl but I've gone to the dark > side on more regular basis over the last year. > > ---------------------------------------------------------- > ----------- To unsubscribe, e-mail: > [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
