Thanks Chris for your reply. Pls do send some of your scripts/configurations, it will be of great help for us!
I also have one question what do you recommend here. We have decided to have 4 physical app servers, and again 4 physcial web server boxes. Most of the application are non critical and can work without session replication etc, so we just want to have sticky sessions enabled from the webserver to the app servers. So do we need add/modify any extra configuration in server.xml than what comes with default tomcat 6.x ? (as we do not need clustering session replication, just sticky sessions). Also regarding connectors, which one do you recommend mod_proxy or mod_jk? Thanks! On Sat, May 23, 2009 at 8:27 AM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > DW, > > On 5/20/2009 1:00 PM, List Member wrote: >> At the same time it should be flexible as it will support >> multiple applications, multiple JVMs, each app very different from >> each other. > > We do this on our production systems. Each application gets its own JVM > which can, of course, be a different version from the others if > necessary (although we try to stick to one JVM for all apps). The same > is true for Tomcat: they can each run under a different TC version, or > share a single install base (using CATALINA_HOME) with others. It's > totally mix-and-match. > > We do this all using ant scripts to convert a relatively generic set of > files along with the code, libraries, etc. into a running instance of > Tomcat (whichever version). We can prepare an installation, deploy the > web app to it, start and stop tomcat, etc. all using simple ant targets. > > Once the environment is set up properly, we just run: > > $ ant install > (builds code, prepares Tomcat based upon shared CATALINA_HOME, > installs the webapp) > $ ant tomcat-start > (starts Tomcat) > > ...and we've got a working application. > > You can even re-name the application (by changing the "project name" in > the build.xml file) and get yourself a different set of configuration > options. So, you can have webapp "foo" and "foo-testing" that each > deploy to a different Tomcat instance that could potentially be on > different JVMs, different Tomcat versions, etc. > >> We are planning to use default appbase and use webapps as directory >> where users will put in their war files. The data source information >> should be in the war file itself. And most of the jar's, extra >> configuration should be built into the war file. The main criteria >> being that we would like to keep the installation as clean as >> possible. > > Exactly why we use the above techniques. Upgrading Tomcat (once we've > testing our apps on it sufficiently :) involves nothing more that: > > $ ant tomcat-stop > $ ant install-clean > $ (edit environment file to point to the new Tomcat CATALINA_BASE) > $ ant install > $ ant tomcat-start > > Upgrade accomplished. > > If you're interested, I could post samples of the ant scripts we use to > perform all this magic. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkoXZi4ACgkQ9CaO5/Lv0PAdrwCePRL2g5MVud+IeiPq/t6X0diB > s8MAnRB1RplRcwnek0tb8eDb5oAo3GeK > =z1TI > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
