Dear Gary,
thanks for your answer.
Actually my main concern is memory usage. I recently had
java.lang.OutOfMemory issues when i had in total 7 similar apps.
Unfortunately i had java 1.4.2. + tomcat 5.0.28 that made difficult to
run a profiler. I switched to java 6 + tomcat 5.5.25 and the system
seems to be more stable now. I tried to add jvm parameters to increase
the memory heap -Xms , -Xmx but i noticed that it got better when i
added |-XX:Permsize| and |-XX:MaxPermSize . The last parameters indicate
more memory for loading the classes (correct me if i am wrong). I know
that it might be a memory leak (i.e. from hibernate) but could it also
be that it loaded all these classes separately and that was causing the
problem ?
Of course i agree that hard space is not an issue at all. The issue now
days is what to do with all the space that we have ;)
|
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 ?
Finally what about having one instance of tomcat per app ? What about
this case ? Here we can be very autonomous (although increases support work)
Regards,
Leonidas
Gary Affonso wrote:
Leonidas Papadakis wrote:
Greetings to all,
i have the following scenario. I want to deploy 5 apps that have
exactly the same classes (in jars). Only db access, static files and
property files change. In short all WEB-INF/lib jar files are the
same. So the question is : option1) If i put the jars under the
common/endorsed directory logically they will be loaded once in the
jvm so that all the applications will find them (common classpath).
option 2) If i keep the WEB-INF/lib structure for each web
application then the classes will be loaded for each application thus
resulting in consuming more memory from the jvm ? I think from my
experience in the second scenario if i do not put the jars in the
WEB-INF folder the application does not start (of course since the
libs are not in classpath) ...
So is it better practice and probably performance wise to place all
jars to tomcat's directory ?
This has not been our practice. We often run separate instances of
the same webapp with only property/config files being different
between the instances.
Having to tear-apart each packaged war just to consolidate the
central/common .jar files just hasn't been worth it.
We keep each app instance (no matter how similar) as a separate
deployable web-application under Tomcat and don't attempt to "share"
common resources via Tomcat's central lib directory (or other
mechanisms).
Now, as for the *effect* of that choice on our part... so far so good.
There's a disk-space hit, I suppose, in having duplicate copies of
most files/libs in each of the webapps. But, jeez, disk space is so
cheap and the file sizes are so small that (to us) it doesn't even
merit concern.
As for JVM memory consumption, you might be right. Each tomcat webapp
gets its own classloader (in general a "very good thing") and I
suppose consolidating shared libs into Tomcat's common classloader
might provide some memory-consumption benefit. I've never looked into
this so I can't answer that definitively one way or the other. For us
the answer is still the same as the disk-space issue: I'd rather buy
more memory than start tearing apart my packaged webapps just to try
and consolidate a few libs and save a few megs. But that's us.
It's really an optimization choice. Do you want to optimize for
disk-space usage/memory usage, or do you want to optimize for ease of
build/installation?
We vastly prefer to optimize for ease-of-build/installation.
Disk-space and memory resources are far *less* precious than our own
developer time. But again, that's us.
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
