DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31405>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31405

[Documentation RFE] unpackwar implications (slow startup)

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://jakarta.apache.org/to
                   |                            |mcat/tomcat-5.0-
                   |                            |doc/config/host.html#Standar
                   |                            |d Implementation



------- Additional Comments From [EMAIL PROTECTED]  2004-09-24 13:01 -------
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.

RFE:
====
If these assumptions are right, I suggest to enhance the documentation at the
above URL to inform the tomcat administrator about these implications.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to