[
https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998429#comment-13998429
]
Adam Heath commented on VFS-142:
--------------------------------
Our current deployment application does not make use of commons-vfs
anymore; we now use more off-the-shelf(but still opensource) tools, and
don't maintain as much internal forks of software as we used to.
After this original bug was filed, I kept finding more and more issues
running commons-vfs in a long-running server environment; from memory,
including, but not limited to:
* long running thread pools(as you mention)
* when nearly out of memory, the app server calls into vfs to read a
file, the vfs extensions we wrote then need to parse xml, this then
attempts to load a class(which was loaded previously, but was thrown
away due to the OOM that will happen shortly), which then calls into a
classloader, which is also backed by the very same top-level vfs
instance; deadlock ensues. This is really more of a bug in
java.lang.Classloader.loadClass, because it is synchronized.
* much use of synchronized in the code base
* not a bug per se, but an ugliness; at the time, there was no generics
in the api.
Due to these, and other issues, I basically ended up just using the vfs
interfaces, and none of the base support classes. All were rewritten,
including the Manager. Final result was generics, no synchronized(uses
java.util.concurrent(aka non-blocking), no dead locks, and no mem-leaks.
Btw, the primary filesystem implementation we had was an 'overlay',
which is similar to linux union; directories could overlay other
directories, getChildren() would be merge, it had support for
whiteouts. There was also support for mount-points at any level. The
metadata for whiteouts was stored as xml as .cowstate.xml(the original
name was COWFileSystem, for copy-on-write). We used this to have a
large, shared BASE, with multiple overlayed CHILDREN. If a child
modified a file, the base was up-copied.
There was also a 'FlatAttribute' file system; getAttribute(name) was
mapped to 'file/path@/name'; this made storing metadata for vfs files
easy, and integrated well with svn and git revision control.
> Clear ThreadData after all streams are closed, fixes a memory leak
> ------------------------------------------------------------------
>
> Key: VFS-142
> URL: https://issues.apache.org/jira/browse/VFS-142
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.1
> Reporter: Adam Heath
> Attachments: fix_ThreadData-clear.patch
>
>
> After all streams are closed in FileContentThreadData, clear the ThreadLocal.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
