[
https://issues.apache.org/jira/browse/ACCUMULO-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644804#comment-13644804
]
Keith Turner commented on ACCUMULO-1321:
----------------------------------------
I modified the unit test to use a jar w/ a class file thats different and it
did not work. I have been deep in the VFS code trying to understand why. I
think I have it figured out for the unit test. The VFS code creates a wrapper
vfs filesystem for a jar/zip, which wraps a java.util.zip.ZipFile. Even after
the file is deleted and recreated, vfs still references the old zip file (the
java zip code keeps an open file handle to the zip file, so even though its
deleted it can still read it). So the new classes in the new jar are not seen.
I was trying to figure out how to clear this internal VFS cache, then I
started thinking this behavior may be desirable. For classloaders created
before the file changed, its nice for them to continue referencing the deleted
zip file. This will result in consistent behavior, where the classloader always
loads classes from one instance of a zip file and not different zip files over
time.
I think the solution is to completely recreate the VFS object when creating a
new classloader. Older classloaders will reference older VFS objects which
will reference deleted zip files. I need to do further work to understand how
this solution works w/ something like HDFS where jar files are copied to a
local tmp dir and then opened using java.util.zip.ZipFile
> 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
