The jar_cache temp files created by sun.net.www.protocol.jar.JarFileFactory never get deleted. As a result, you eventually run out of disk space, and deployed applications and services start failing.  This is a serious problem when using downloadable jar files for codebases in RMI.The jar_cache temp files created by sun.net.www.protocol.jar.JarFileFactory never get deleted. As a result, you eventually run out of disk space, and deployed applications and services start failing.  This is a serious problem when using downloadable jar files for codebases in RMI.

N/A

Using a fixed size hash table to cache the loaded jar files would solve the problem. A retirement policy can be used to retire entries in the cache when
the cache becomes full. When a certain entry is retired, its corresponding temp file
can be deleted. But this fix would be too complicated to put in at this stage,
I am downgrading it to P4 for later possible considerations.

The two suggested fixes will either not solve the problem correctly or totally.
Deleting the temp file in the finally block is wrong, since the temp file is
needed by the corresponding jar file if the jar file is to be cached. Using
file.deleteOnExit will only delete the files when the JVM exits and will not
solve the problem for long running applications.


 xxxxx@xxxxx  1998-08-17

Respond to the new comments:
If you call tmpfile.delete() while this tmpfile is being opened by a JarFile,
on unix, the call would succeed while on win32 it will simply fail. So calling
delete() in the finally clause will not solve the problem at all.

 xxxxx@xxxxx  1998-08-25


This has been partly fixed in 1.2fcs by inserting an appropriate call to
File.deleteOnExit.  See 4180369.  --  xxxxx@xxxxx  1998/10/9

For the record, the partial fix for 4180369 didn't work on win32 because
of bug 4171239.


 xxxxx@xxxxx  1999-04-27

We have fixed this problem in Kestrel. The JarFileFactory will use special
jar files which are deleted automatically once they are closed. This solves
the problem on win32.

 xxxxx@xxxxx  1999-05-25

The Release Fixed entry says it is a non-public 
release.  Will the fixed be incorporated into the 
upcoming 1.2.2 release?  If not, we need to 
re-open the bug.

I'm so glad this is fixed in the non-public 
"Kestrel" release!
HOW BOUT A LITTLE COMMUNICATION HERE AS TO WHEN
MY CLIENTS AND I CAN EXPECT TO SEE THIS IN A 
REAL RELEASE!!  WHEN AND WHERE?  Thanks...

I was so excited to find out that the bug was closed and fixed when I checked
here about 2 months ago.  I expected it to be included in JRE 1.2.2.  But the
problem turns out to be still there.  It is not fixed and should be re-opened. 
Thanks,

I have the same problem with 1.2.2 and Win32
For example if I create an ImageIcon like this
ImageIcon imageicon = new ImageIcon( gifURL );
where the gifURL relates to a gif in a jarfile on a other machine,
in my C:Temp a jar_cache is generatet and not deleted. If you want 
to delete it by hand it´s not possible. You also can not delete the 
related Jarfile on the other machine (but this is necessary in 
my application)
If I shut down the application all Jarfiles can be deleted... But the
Tempfile is not delete automatically..

This bug still exists in kestrel-beta (aka. v1.3 beta). The plugin gets its
files delivered
as jar_caches<nnn>.tmp as well.
But it got better: the files are now truncated to 0 bytes (at least on Windows
NT).

Is there any chance of getting this bug fixed in 1.2.2-xxx?
It looks like it has never been reopened.
There should be some work-around as well: I've discovered the bug only after
archiving
the whole applet into one jar and signing it. My C:\TEMP was clean when I had
only
one unsigned jar plus number of .class and .gif files.

We verified this feature using JDK 1.3 beta and IE5 and found that the file in
the temporary directory was NOT DELETED by the file size was set to zero.
Can someone verify that the bug is really fixed ?

On win 95 with 1.3 beta, the files remain, but become 0 bytes. Why can't the
plugin delete them if it can set zero them out?

We are still seeing this problem with the released 1.3 
plugin.  This is definitely not fixed.  On our systems, the 
files were not even truncated to size 0.

Has this been fixed in release 1.2.2_006 of the JRE?

We have a concern that this fix introduces a new bug on Linux, using 'lsof', its clear that file handles are left opened and not properly closed when jar_cache files are deleted, this eventually lead to the consumption of all handles available in linux and the next request for a handle usually results in an OutOfMemory error that another Thread cannot get created. This error is obvious when working with tomcat under a heavy load.

It would be good to verify that on the linux distribution that when the jar_cache files are removed that their corresponding handles are also properly closed. Otherwise, such long running processes like tomcat crash over time.

This is still problem on jre1.4.1

jre-6u1 also have this problem!

Hmmmm.   My testers are seeing this behavior with the latest JRE running an applet.  Perhaps a regression?

This is also occurring with jre-6u3....  Please fix this.