[
https://issues.apache.org/jira/browse/ACCUMULO-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644838#comment-13644838
]
Keith Turner commented on ACCUMULO-1321:
----------------------------------------
Some notes on the code I found in VFS. As I look more closely at this code,
the behavior my be slightly different than what I described in my previous post.
* o.a.c.vfs2.provider.jar.JarFileProvider extends
o.a.c.vfs2.provider.zip.ZipFileProvider extends
o.a.c.vfs2.provider.AbstractLayeredFileProvider
* o.a.c.vfs2.provider.AbstractLayeredFileProvider.createFileSystem() will
look in a cache (this is a protected cache, not the one specified by the user).
This is the function that will return a cached JarFileSystem.
* o.a.c.vfs2.provider.zip.ZipFileSystem.init() will place
java.util.zip.ZipEntry objects into another cache (the cache specified by the
user). These could age off, which may result in different behavior than I
described above. Need to look into this further.
> Dynamic Classloader lost jars
> -----------------------------
>
> Key: ACCUMULO-1321
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1321
> Project: Accumulo
> Issue Type: Bug
> Reporter: John Vines
> Assignee: Keith Turner
> Fix For: 1.5.0
>
>
> We have a table setup that uses some custom iterators. We ran an MR job
> against it without issues. We then ran the job immediately after the first
> one wrapped and 2 of my tservers errored with ClassNotFoundException, even
> though it ran just fine before.
> Unfortunately we don't have a stack trace (to see if it was breaking
> differently in the VFSClassLoader), nor a convenient way to recreate
> currently. We're working on reproducing it in order to get more information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
