[
https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998149#comment-13998149
]
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)
