You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "John Sisson (JIRA)" <de...@geronimo.apache.org> on 2006/01/13 01:25:20 UTC
[jira] Created: (GERONIMO-1464) Avoid use of file.deleteOnExit() -
will cause allocation of 1K of memory per call until JVM terminates
Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
------------------------------------------------------------------------------------------------------
Key: GERONIMO-1464
URL: http://issues.apache.org/jira/browse/GERONIMO-1464
Project: Geronimo
Type: Bug
Components: Memory Leaks
Versions: 1.0
Reporter: John Sisson
Priority: Minor
Fix For: 1.1
I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1464) Avoid use of file.deleteOnExit() -
will cause allocation of 1K of memory per call until JVM terminates
Posted by "Vamsavardhana Reddy (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1464?page=all ]
Vamsavardhana Reddy updated GERONIMO-1464:
------------------------------------------
Patch Info: [Patch Available]
> Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
> ------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-1464
> URL: http://issues.apache.org/jira/browse/GERONIMO-1464
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Memory Leaks
> Affects Versions: 1.0
> Reporter: John Sisson
> Priority: Minor
> Fix For: Wish List
>
> Attachments: G-1464.patch
>
>
> I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
> According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1464) Avoid use of file.deleteOnExit()
- will cause allocation of 1K of memory per call until JVM terminates
Posted by "John Sisson (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1464?page=comments#action_12362591 ]
John Sisson commented on GERONIMO-1464:
---------------------------------------
I think Kevan had some ideas about file cleanup, maybe he can add some comments. I agree we need to ensure these files get deleted.
> Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
> ------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-1464
> URL: http://issues.apache.org/jira/browse/GERONIMO-1464
> Project: Geronimo
> Type: Bug
> Components: Memory Leaks
> Versions: 1.0
> Reporter: John Sisson
> Priority: Minor
> Fix For: 1.1
>
> I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
> According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1464) Avoid use of file.deleteOnExit()
- will cause allocation of 1K of memory per call until JVM terminates
Posted by "Aaron Mulder (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1464?page=comments#action_12362577 ]
Aaron Mulder commented on GERONIMO-1464:
----------------------------------------
I know I've used it in a number of places. Can we implement our own utility method to do this (and just register it as a shutdown hook with the kernel)? I don't want to just not delete things either.
> Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
> ------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-1464
> URL: http://issues.apache.org/jira/browse/GERONIMO-1464
> Project: Geronimo
> Type: Bug
> Components: Memory Leaks
> Versions: 1.0
> Reporter: John Sisson
> Priority: Minor
> Fix For: 1.1
>
> I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
> According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1464) Avoid use of file.deleteOnExit() -
will cause allocation of 1K of memory per call until JVM terminates
Posted by "Matt Hogstrom (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1464?page=all ]
Matt Hogstrom updated GERONIMO-1464:
------------------------------------
Fix Version/s: Wish List
(was: 1.2)
Moving out for a later version.
> Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
> ------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-1464
> URL: http://issues.apache.org/jira/browse/GERONIMO-1464
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Memory Leaks
> Affects Versions: 1.0
> Reporter: John Sisson
> Priority: Minor
> Fix For: Wish List
>
>
> I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
> According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1464) Avoid use of file.deleteOnExit()
- will cause allocation of 1K of memory per call until JVM terminates
Posted by "Kevan Miller (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1464?page=comments#action_12362674 ]
Kevan Miller commented on GERONIMO-1464:
----------------------------------------
John, good find about the memory consumption of deleteOnExit().
Aaron, yes. I think we need a utility to track our file usage and manage cleanup. I don't think a shutdown hook is sufficient, however. There needs to be periodic housekeeping...
Prior to 1.0, I made some changes to improve the usage of temporary files/configuration files. (Note I didn't say "fix" :-). These changes were to config-store and remote-deploy code. I didn't look at any of the console code...
I've seen deleteOnExit() used in two ways.
1) After an explicit delete() failed. We'd try to use deleteOnExit() to attempt to delete the file later. On Windows, it was my observation that this didn't work -- the files were usually (never?) deleted, even after exit. I removed these deleteOnExits() and added config-store and temporary file "reapers". Config-store files should now always be cleaned up -- either while the server is running, or after a server is restarted. There are cases where temporary files will never be deleted (if not deleted before a server restart).
2) When there was no explicit life cycle for a file (i.e. a file was created, but we weren't tracking when it could be deleted). In most/all cases, I think it will be pretty easy to impose explicit life cycle usage for these files.
I see the following work items:
1) Define explicit lifecycles for the files we create and delete (or attempt to delete) when we are done with them. This involves conig-store, remote-deploy, and console code. Any others? If absolutely necessary, we can define deleteOnExit semantics. However, I'd rather not...
2) Create a common file reaper that can be used to delete files when the initial file deletion fails. This basically applies to Windows. A list of files pending deletion should be maintained across server restarts. As Aaron suggests, we could attempt to delete the files as part of shutdown processing. However, there's no guarantee that we'll be able to delete files, even then...
3) Create our own UrlClassLoader that can be explicitly closed and thus release the jar files it's referencing. We're currently dependent upon the UrlClassLoader being GC'ed before this can happen.
> Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
> ------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-1464
> URL: http://issues.apache.org/jira/browse/GERONIMO-1464
> Project: Geronimo
> Type: Bug
> Components: Memory Leaks
> Versions: 1.0
> Reporter: John Sisson
> Priority: Minor
> Fix For: 1.1
>
> I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
> According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1464) Avoid use of file.deleteOnExit() -
will cause allocation of 1K of memory per call until JVM terminates
Posted by "Vamsavardhana Reddy (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1464?page=all ]
Vamsavardhana Reddy updated GERONIMO-1464:
------------------------------------------
Attachment: G-1464.patch
G-1464.patch:
I have scanned the trunk (rev 490474) and found references to deleteOnExit() in the following classes:
o DatabasePoolPortlet
o ActiveMQConnectorHelper
o AbstractHandler
o RepositoryViewPortlet
o SecurityRealmPortlet
o DeploymentContextTest
o AbstractDeployCommand
o FileUploadServlet
o DeploymentUtil
o PluginInstallerGBean
Except for PluginInstallerGBean, all other classes are calling deleteOnExit() immediately upon creating a temporary file. PluginInstallerGBean is calling deleteOnExit() when delete() fails. Except for DeploymentUtil, I have replaced the use of deleteOnExit() by first attempting a delete and calling deleteOnExit() only when delete fails. The patch has taken care of the scope of the file usage. IMO, this patch is definitely an improvement over what exists now.
> Avoid use of file.deleteOnExit() - will cause allocation of 1K of memory per call until JVM terminates
> ------------------------------------------------------------------------------------------------------
>
> Key: GERONIMO-1464
> URL: http://issues.apache.org/jira/browse/GERONIMO-1464
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Memory Leaks
> Affects Versions: 1.0
> Reporter: John Sisson
> Priority: Minor
> Fix For: Wish List
>
> Attachments: G-1464.patch
>
>
> I haven't run into a memory problem but came across this bug in Sun's bug database and a number of people warning not to use deleteOnExit() in server code.
> According to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817 each call to file.deleteOnExit() will allocate 1K of memory until the JVM terminates. I have not had the chance to verify it, but I have raised this JIRA in case someone is tracking a memory leak in the future or someone has time to review our usage of deleteOnExit().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira