DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Summary: antiJARLocking and antiResourceLocking with many lib
jars causes performance degradation and reload failure.
Product: Tomcat 5
ReportedBy: [EMAIL PROTECTED]
Here is a catch-22.
We want to use deployer to deploy web applications to target servers. It
formalises the process of build a little more. However, deployer does not work
well on Windows as JARs get left behind. Furthermore another bug I submitted
yesterday shows that deploying, restarting the Windows service and then
That restart bug aside, in order to even get deploy and undeploy to work we
have to use antiJARLocking="true" antiResourceLocking="true" on our context.
I added this just the other day and I noticed that starting Tomcat took a whole
lot longer than usual (nearly 1 minute), and that compiling class changes to my
development Tomcat did not cause the usual web application reload (as indicated
by reloadable="true" on the context).
I decided that the only thing I changed was the antiJARLocking="true"
antiResourceLocking="true" attributes. I took them off today and Tomcat starts
up in 20s. Furthermore, compiling class changes works again.
I thought about why this might be and we have 18M of lib JARs. In order for the
anti locking to work I notice that copies are made to a temp folder. I can only
assume therefore that having so many JARs in a web application lib combined
with using the anti locking features causes this huge degradation in ability to
develop and test.
I've made sure this is definately the problem by adding and removing the
antiJARLocking="true" antiResourceLocking="true" attributes a few times, and it
always varies from 58s and no reloading with them set to true and 20s and
reloading ok with them false.
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]