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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
