-
Bug
-
Resolution: Fixed
-
P4
-
1.4.2
-
b32
-
generic
-
generic
URLJarFile.retrieve fails to delete the jar_cache tmpFile if an IOException occurs when reading from the input stream (or when writing to the output stream). This can result in accumulation of unused files in the temp directory, and can lead to unnecessary out-of-disk-space failures.
As an example of this, we have an httpmd: URL type that we use for referring to jar files, which also includes a message digest for the jar file contents. If the contents of the jar file are changed, subsequent attempts to load the jar file through the original httpmd: URL will cause an IOException to be thrown when URLJarFile.retrieve reads the input stream (because the digests don't match). This leaves a file in the temp directory. Depending on the application, there may well be repeated attempts over time to read from that URL, each one adding to the file accumulation. Because the IOException is thrown at the end of reading the entire contents, each file left around contains the complete jar contents, so the sizes can add up over time.
As an example of this, we have an httpmd: URL type that we use for referring to jar files, which also includes a message digest for the jar file contents. If the contents of the jar file are changed, subsequent attempts to load the jar file through the original httpmd: URL will cause an IOException to be thrown when URLJarFile.retrieve reads the input stream (because the digests don't match). This leaves a file in the temp directory. Depending on the application, there may well be repeated attempts over time to read from that URL, each one adding to the file accumulation. Because the IOException is thrown at the end of reading the entire contents, each file left around contains the complete jar contents, so the sizes can add up over time.
- relates to
-
JDK-4960962 (so) SocketChannel.close() does not close immediately when channel is registered
-
- Resolved
-