Bug 37020 - antiJARLocking and antiResourceLocking with many lib jars causes performance degradation and reload failure.
Summary: antiJARLocking and antiResourceLocking with many lib jars causes performance ...
Status: RESOLVED INVALID
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.9
Hardware: Other other
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-11 15:50 UTC by Allistair Crossley
Modified: 2005-10-12 06:43 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allistair Crossley 2005-10-11 15:50:26 UTC
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 
undeploying breaks.

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.
Comment 1 Remy Maucherat 2005-10-12 12:53:16 UTC
This is not a bug. The webapp is indeed deployed over to another location, which
takes time.
Comment 2 Allistair Crossley 2005-10-12 12:58:04 UTC
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.

thanks anyway.
Comment 3 Remy Maucherat 2005-10-12 14:23:36 UTC
(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.
Comment 4 Allistair Crossley 2005-10-12 14:43:04 UTC
>> BTW, your other bug report is bad.

is it? or is it just that Tomcat does not offer any reasons for its failures 
and I am led to believe there is a problem because of the unexpected behaviour?

the bug report lists precise steps to a failure that should not be there or if 
there is a reason should be reported to the user.

consider it another enhancement than a bug if that is the case.