Bug 31405 - [Documentation RFE] unpackwar implications (slow startup)
Summary: [Documentation RFE] unpackwar implications (slow startup)
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.0.28
Hardware: Other other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL: http://jakarta.apache.org/tomcat/tomc...
Depends on:
Reported: 2004-09-24 12:42 UTC by Ralf Hauser
Modified: 2004-11-16 19:05 UTC (History)
0 users

startUp.png quality analyzer (33.70 KB, image/png)
2004-09-24 12:44 UTC, Ralf Hauser

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2004-09-24 12:42:39 UTC
Comment 1 Ralf Hauser 2004-09-24 12:44:48 UTC
Created attachment 12856 [details]
startUp.png quality analyzer
Comment 2 Remy Maucherat 2004-09-24 12:56:18 UTC
Let's not waste anyone's time with this "quality" metric. If you want to suggest
changes, please provide patches.
Comment 3 Ralf Hauser 2004-09-24 13:01:21 UTC
my tomcat server has 4 servlets loaded multiple times by 3 connectors (in 3
different wars).

In order not to have to clean after these instances I put unpackwar=false.
As a minor security consideration, each time less the files are on the disk, the
smaller is the exposure (albeit an informed attacker would anyway be most
interested in the ./work/*/_* directories).

Anyway, being aware that this would reduce startup, time, I was surprised about
the accelerated deterioration of startup time as my application and the number
of jsp's grew. It's roughly 300 struts-related classes and 300 jsps. On an intel
machine one generation behind, it easily took 5 minutes or more to start,
especially, the super.init() method of the four servlets took ages.
As per the attached screenshot, I guess the reason for this is the unpackwar
that throws over 10'000 (probably planned?) exceptions (WARDir*...) and might
unpack the war many times.

If these assumptions are right, I suggest to enhance the documentation at the
above URL to inform the tomcat administrator about these implications.
Comment 4 Remy Maucherat 2004-09-24 13:52:29 UTC
Even if it is the problem (which I'm not sure of), it will be very difficult to
I'd like to point out that the regular file based stuff creates as many of these
exceptions, and, generally, Struts webapps startup is extremely slow.
Comment 5 Ralf Hauser 2004-10-05 06:42:47 UTC
further observations that may help others:
1) when setting CATALINA_OPTS="-verbose:gc" I see about 300 garbage collections:
[GC 18619K->3026K(260160K), 0.0217930 secs]
[GC 19218K->3011K(260160K), 0.0047730 secs]
[GC 19191K->3011K(260160K), 0.0033220 secs]
[GC 19203K->3013K(260160K), 0.0039100 secs]
[GC 19205K->3100K(260160K), 0.0047540 secs]
[GC 19292K->3125K(260160K), 0.0045940 secs]
[GC 19316K->3143K(260160K), 0.0042910 secs]
[GC 19328K->3167K(260160K), 0.0043550 secs]
[GC 19654K->3458K(260160K), 0.0009390 secs]
[Full GC 12290K->3530K(260160K), 0.0917670 secs]
[GC 19784K->3811K(260224K), 0.0043500 secs]
[GC 20465K->4217K(260224K), 0.0011250 secs]
[GC 20471K->4215K(260224K), 0.0010260 secs]
[GC 20466K->4222K(260224K), 0.0010590 secs]
[GC 20478K->4242K(260224K), 0.0013500 secs]

2) when running jprobe memorydebugger, it ends up with excessive memory use and
swapping such that a warm reboot of the machine is more promising than waiting
for the console to respond on simple key entries ... (gijs.bruyn@quest.com from
JProbe support suspects unpack=false to be the main culprit)