Why shouldn't i turn on "antiJARLocking" in production environment?

Question

I'm running web-apps on a Tomcat7 server and having trouble undeploying them. It seems that windows keeps a lock on a particular JAR file in the application folder. I've found that there is a context attribute called "antiJARLocking" that i can set to 'true' (defined here: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Standard_Implementation) that may solve the problem.

The fact is, i've seen a couple of people stating that i should NOT set this attribute to true in a production environment; but i can't find what are the reasons for that. I know that setting this attribute to true may slow down tomcat startup and/or application startup, but this does not sound like a big problem to me..? Am i wrong?

Do you know any other reason that would explain why some may discourage the use of "antiJARLocking" in production? Is there any other solution to JAR locking problem?

If this can be of any help, i'm running tomcat 7.0.40. The jar file that keeps getting locked is "ojbdc6.jar".

Thank you for your help!

Lycanthrope

https://mcmap.net/q/429711/-tomcat-6-what-39-s-the-significance-of-antiresourcelocking-amp-antijarlocking – Goldsberry

« [...] tomcat did a copy of the webapp in the temp dir. This makes the deployment slower and with nearly each redeploy the temp dir grew in size, so I had to make a procedure to delete older deployments of my app from the temp dir. » That's useful information! Thanks. I also agree with « [...] and with java it's always a good idea to do a server restart after redeploy in production (an OutOfMemoryError is always lurking in the dark, even if your own code doesn't leak) » – Lycanthrope

This antiJARLocking option is gone in Tomcat 8. Instead, see antiResourceLocking in the Context Container documentation. – Ind

Answer 1

Tomcat's anti-resource locking features are provided to work around bugs in deployed web applications that result in files being opened but not closed. On some operating systems - primarily Windows - this prevents the file from being deleting which in turn prevents the web application from being fully undeployed. Usually, the only way to delete those files is to stop Tomcat first. The anti-resource locking copies the web application to a uniquely named directory in the work directory and deploys it from a there. Each redployment gets a new directory so not being able to delete the old directory is not an immediate problem.

There is no specific reason why the anti-resource locking features should not be used in production. However, you do need to be aware that locked files are effectively a memory leak and after multiple redeploys you may end up filling permGen and triggering an OOME.

The quick and dirty solution to odbc6.jar being locked is to move it from WEB-INF/lib to $CATALINA_HOME/lib. The better solution is to figure out why it is locked (you'll probably need to use a combination of a profiler and a debugger to find the root cause) and fix it.

Pellegrino

Answer 2

According to this wiki,

You should NOT turn this option on in production. The antiResourceLocking option can stop JSPs from redeploying when they are edited (a reploy [sic] of the webapp is required instad [sic] and sometimes a clean out of the work directory). There are small restrictions apparently on not being able to get certain kinds of resource paths to webapp resources for webapps that are being run from the special "temp" area but we have never run into them in practice.

Goldsberry

I dont think it's a good idea to modify a JSP page directly in production anyway; but still, this is good to know. – Lycanthrope