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=37020>.
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=37020





------- Additional Comments From remm@apac...  2005-10-12 14:23 -------
(In reply to comment #2)
> i thought it may not be a bug, i've changed the severity to "enhancement" to
> make that clear.
>
> there is clearly an issue with deployer on windows machines, and coupled with a
> large web application this kind of performance is not workable when the anti-
> locking strategy is put in place.  
>
> i suppose the answer will be to add anti locking for deployed applications only
> and keep dev setups without the anti locking off.
>

If you have zillions of JARs, then there's no solution. The MS stuff and the Sun
JVM seem to both be optimized so that JAR file locking (or even regular file
locking) will almost always occur. The workaround for all problems is to copy
the whole thing to the temp folder, and just run it from there. JBoss does the
same thing to allow hot deployment.

The other workaround is to consider using OSes with more flexible filesystems.

I told you already that antiJARLocking and antiResourceLocking don't do the same
thing, and using both is not very useful. BTW, your other bug report is bad.


--
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: tomcat-dev-unsubscribe@jaka...
For additional commands, e-mail: tomcat-dev-help@jaka...