Leonidas Papadakis wrote:
Also if apart from the dependency libraries, if you gather all your
classes in a jar file isn't it easier to overwrite one file so that all
apps will receive the update at once ?
In our case we rarely want each instance to be updated at the same time.
We're typically running slightly different versions of each app (a
staging version, a testing version, etc.)
We've found it *way* better for developer sanity (in this case) just to
treat each app as a little atomic unit. If we update the staging
server's Hibernate version from 3.1 to 3.2 we almost certainly do *not*
want to apply that update to the production server at the same time. We
want to test the update within the confines of the staging server
instance before we roll out that change.
If this was a cluster of all the *exact* same app I might be tempted to
consolidate shared resources. But in our case it's the wrong optimization.
Finally what about having one instance of tomcat per app ? What about
this case ? Here we can be very autonomous (although increases support
work)
There's a mode in Tomcat called "multiple instance mode" or something
like that. It allows you to have a central Tomcat install dir and then
create "config" dirs for each additional tomcat instance.
A good tutorial on how to set this up is here...
http://azeditech.com/tomcat/multiple-tomcat-instances.html
(As it sounds like you know, this is different than running each *app*
as an instance inside a single tomcat server. This allows you to run
multiple *tomcat* instances in which you can run one or more apps.)
We've been running our various app versions (staging, testing, dev) this
way for awhile (dedicating one tomcat instance to each app) and we
really like it.
One benefit is that you can restart the entire Tomcat server for one app
without affecting the others. It also gives us more "peace of mind"
knowing that each app is running under a separate JVM.
But I find the added complexity of the "multiple" instance configuration
to be more of a pain than it's worth.
I'd rather just install 3 full tomcat "runtime" binaries (and associated
directory tree) and do a normal config of each.
Consolidating to one Tomcat directory with supplemental config dirs for
each tomcat instance buys us nothing practical over just running three
instances of Tomcat each with it's own "full" installation directory.
And running the "multiple instance" configuration (from a central
binary) is fairly uncommon (in my experience) which just tends to
confuse new Tomcat administrators that you introduce to the system.
In short: I like having one Tomcat instance per app. That's been really
helpful for us. But I'm not particularly impressed with using Tomcat's
"multiple instance from a common binary" configuration option to achieve
that. Better, IMO, just to create those multiple instances with "full"
installation directories for each instance.
- Gary
P.S. Hopefully it's obvious that any multiple Tomcat instance solution
(whether a shared binary or a single-binary-per-instance) will require
that each instance (and therefore each app) listens on a unique port.
The ability to do "virtual" hosts goes away (as far as I know).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
