ok so at the end of the day you are in favor of one instance of tomcat
per application...
I think i will adapt this solution since although you can restart an
application from tomcat's manager, i have the feeling that a "corrupted"
jvm will not "clear" correctly...
Regarding the virtual hosts, i think apache is not interfered at all
(connecting via different workers) so you can set any virtual host ...
Regards,
Leonidas
Gary Affonso wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
