United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 5098318 Cached Jar file should be released on appl. exit even that is opended by Cipher
5098318 : Cached Jar file should be released on appl. exit even that is opended by Cipher

Details
Type:
Bug
Submit Date:
2004-09-08
Status:
Resolved
Updated Date:
2005-09-16
Project Name:
JDK
Resolved Date:
2005-09-16
Component:
security-libs
OS:
generic
Sub-Component:
javax.crypto
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_05
Fixed Versions:
6

Related Reports
Backport:
JDK-2128484 - Cached Jar file should be released on appl. exit even that is opended by Cipher
Backport:
JDK-2126786 - Cached Jar file should be released on appl. exit even that is opended by Cipher
Relates:
JDK-5041014 - URLClassLoader.getResourceAsStream locks jar files
Relates:
JDK-6321722 - On windows, sometimes jar file cannot be deleted even when there is no reference to it
Relates:
JDK-6423370 - Fix for bug 5098318 prevents caching of JAR files containing cipher code

Sub Tasks

Description
A customer found the case where files in .war can not be deleted
in some Web application which uses  javax.crypto.Cipher 
even if undeploy are executed.

CONFIGURATION:
 JDK:JDK1.4.2_05
 Tomcat 5.0.25 


BEHAVIOR :
 The files under webappls directory can not be deleted after undeploy 
 with Tomcat Manager.
 Because the files are not deleted, application can not be deployed 
 after the customer changes the application.
 
.........
        at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:67)
        at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.ja
va:85)
        at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection
.java:69)
        at javax.crypto.SunJCE_e.run(DashoA6275)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.SunJCE_d.b(DashoA6275)
        at javax.crypto.SunJCE_d.a(DashoA6275)
        at javax.crypto.SunJCE_d.a(DashoA6275)
        at javax.crypto.SunJCE_b.b(DashoA6275)
        at javax.crypto.SunJCE_b.a(DashoA6275)
        at javax.crypto.SunJCE_g.a(DashoA6275)
        at javax.crypto.SunJCE_g.a(DashoA6275)
        at javax.crypto.SunJCE_b.a(DashoA6275)
        at javax.crypto.SunJCE_b.a(DashoA6275)
        at javax.crypto.Cipher.a(DashoA6275)
        at javax.crypto.Cipher.getInstance(DashoA6275)
        at HelloWorld.encode(HelloWorld.java:41)
        at HelloWorld.init(HelloWorld.java:17)
        at javax.servlet.GenericServlet.init(GenericServlet.java:211)


INVESTIGATION :
   It turned out the jar file included in the appication is saved  in cache of
   sun.net.www.protocol.jar.JarFileFactory called from  javax.crypto.Cipher.
   We can control cache on/off with using setUseCaches(false) in usual our
   application. However, in the above case, because the cache control is done 
   in javax.crypto.Cipher, we can not do anything to control cache.

REQUEST:
  If Cipher really opens jars in user application and hold,
  it seems that Cipher should release or purge cached jars on the application's
  exit.
  Otherwise, please provide some workaround.

======================================================================

Comments
EVALUATION

6321722 was filed, and following promotion of that fix (b59), Valerie reports:

========
Both the modified (which I modified to remove the dependency on JCE) and
the original (which uses JCE) testcase work as expected, i.e. fail on
b58 and pass on b59.

Guess we finally have this hard-to-trace bug nailed down and fixed. :)
========

Yay...that burned way too many cycles!
2005-11-15 
EVALUATION

I generated another testcase based on the current testcase but without calling
into JCE. This looks very much like a GC issue as the test is very fickle and
there is no single API call which would cause the behavior to change.

Anyway, I've filed 6321722 "On windows, sometimes jar file cannot be deleted even when there is no reference to it" to keep track of this. Thus, I have attached
the JCE regression test (JarCachingTest.java) for verifying the fix in mustang.
2005-09-08 
EVALUATION

As part of JCE export requirement, JCE framework has mechanisms
which would check the crypto configuration of the system 
(JCE jurisdiction policy file) and the calling apps (optional
permission files bundled with the app) and determine the
available crypto algorithms and their max key length.

Thus, JCE framework would access caller codebase as well as
several other jars in order to determine the allowed crypto
strength. The accesses are through JarURLConnection and caching
is on *by default*. The current JarURLConnection impl does
not seem to allow its callers to purge or delete the cached 
jars. 

Will have to disable caching unless the current JarURLConnection
impl can be fixed/enhanced to support the file purging.

###@###.### 2004-11-19 22:33:57 GMT
###@###.### 2004-11-19 22:34:10 GMT

We have provided a fix in 1.4.2_10 that also works in tiger,
but for some reason the same fix is not working in mustang.  I'm pretty
sure the problem is in either the GC or in the Zip file code.  I took
a large chunk of the JCE jar verification code out, and watched it
iterate over the 8 jar entries (skipping the rest) and it worked fine,
but on the 9th (skipping the rest), it failed.  I'm pretty sure it's GC, but
need to move the zip/jar code from tiger into mustang to remove this
possibility.

###@###.### 2005-06-07 00:13:39 GMT
2004-11-19


Hardware and Software, Engineered to Work Together