Plague of temp VFS files and OOM on redeploy
alesj Jan 13, 2009 8:42 AMWRT
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=147622&start=20
I already did some changes, but they are not solving all the problems users face.
The problems:
(1) expire of VFS cache entries lead to plague of temp files
(2) the temp files are never deleted
(3) re-deploy causes OOM on VFS code
What I did and/or what is still to do:
(1) I added Combined VFS cache where part of it is permanent entries (most common roots),
the other part is real cache - any of the VFSCache impls
(2) I'm currently looking into the issue,
eventually closing VirtualFileHandler when it's no longer used
e.g. in FileHandler update --> closing cached/old child handlers
Current code keeps a ref track on VirtualFileHandler usage,
only to allow close when ref == 0.
But in FileSystemContext we keep root's VirtualFileHandler ref from the beginning.
/** A reference to the virtual file of the root to stop it getting closed */ private VirtualFile rootFile; public VirtualFileHandler getRoot() throws IOException { if (root == null) { root = createVirtualFileHandler(null, file); if (root == null) throw new java.io.FileNotFoundException((file == null ? "<null>" : file.getName()) + " doesn't exist. (rootURI: " + getRootURI() + ", file: " + file + ")"); rootFile = root.getVirtualFile();
What's the purpose of this? (see comment/usage)
This prevents me from closing something like this:
- my.ear/ui.war/lib/tools.jar
Where I would want to close my.ear's VirtualFile ref,
eventually closing all nested entries -- actually also deleting its matching temp files.
The new code to ZipEntryContext does that:
public void close(ZipEntryHandler handler) { VirtualFileHandler rootHandler = getRoot(); if (rootHandler.equals(handler)) { getZipSource().close(); // only close nested - as they might be temp files we want to delete for (VirtualFileHandler vfh : nestedHandlers) { vfh.close(); } } }
(3) I only got this via user feedback, hence not really tested
And like the users says, the real cause might be elsewhere.
But Marko promised to have a look anyway. :-)
The user also notes that this wasn't an issue in previous JBossAS versions.
But after starting small internal discussion I'm no longer persuaded that that's really true,
as I didn't get any (internal) feedback that would point me to some real proof that we actually did things any different,
different from File.deleteOnExit or deleting temp at boot time.
It might be just the simplicity of what we did before that resulted in things working.
Looks like that what might work for users, doesn't quite work for us yet
- simplicity vs. VFS's API. But we'll get there. ;-)