[ 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
