accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1321) Dynamic Classloader lost jars
Date Mon, 29 Apr 2013 19:56:16 GMT


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   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

> Dynamic Classloader lost jars
> -----------------------------
>                 Key: ACCUMULO-1321
>                 URL:
>             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:

View raw message