tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: svn commit: r830736 - in /tomcat/trunk/java/org/apache/catalina/core: JreMemoryLeakPreventionListener.java LocalStrings.properties
Date Thu, 29 Oct 2009 00:50:30 GMT
2009/10/28  <markt@apache.org>:
> Author: markt
> Date: Wed Oct 28 19:25:31 2009
> New Revision: 830736
>
> URL: http://svn.apache.org/viewvc?rev=830736&view=rev
> Log:
> Add a workaround for a common cause of locked files.
>
> Modified:
>    tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java
>    tomcat/trunk/java/org/apache/catalina/core/LocalStrings.properties
>
> +             * Several components end up opening JarURLConnections without first
> +             * disabling chaching. This effectively locks the file. Whilst more

A typo:

s/chaching/caching/

> +                URL url = new URL("jar:file://dummy.jar!/dummy.txt");
> +                URLConnection uConn = url.openConnection();
> +                uConn.setDefaultUseCaches(false);

What I can see from JDK sources as of 6u15,
URLConnection#defaultUseCaches field is static and thus is shared by
all subclasses.

Thus this setting will affect not only JAR files, but e.g.
sun.net.www.protocol.http.HttpURLConnection#getInputStream()
-- there is a getUseCaches() call, which determines whether the
java.net.ResponseCache cache will be used or not.

Even if we agree to include this feature in
JreMemoryLeakPreventionListener, there should be an easy way to turn
it off. Also I would propose to turn it off by default.


Regarding implementation:

The "file://dummy.jar" URL apparently is a relative one and references
a file in the current working directory.  No file operations are
actually performed in those calls, so I think that actually does not
matter.

I thought of an alternative implementation:  to create a dummy
subclass of URLConnection, and call its setDefaultUseCaches() method.
But using Mark's method should be better, in view of possible Java API
changes.

Also, "dummy.txt" part of the URL is not necessary. It would be
sufficient to end the URL with "!/", see syntax here:
http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html


Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message