You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Konstantin Kolinko <kn...@gmail.com> on 2009/10/29 01:50:30 UTC
Re: svn commit: r830736 - in /tomcat/trunk/java/org/apache/catalina/core:
JreMemoryLeakPreventionListener.java LocalStrings.properties
2009/10/28 <ma...@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
Re: svn commit: r830736 - in /tomcat/trunk/java/org/apache/catalina/core:
JreMemoryLeakPreventionListener.java LocalStrings.properties
Posted by Mark Thomas <ma...@apache.org>.
Konstantin Kolinko wrote:
> 2009/10/28 <ma...@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/
Fixed.
>
>> + 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.
Happy with making it configurable. Not so sure about changing the
default. I see more issues with apps locking files that I see apps
making outbound connections.
> 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.
That was my thinking.
> 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
I'll clean that up.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org