accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Marion (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-708) Modify ClassLoader to support different applications / multi-tenancy
Date Wed, 14 Nov 2012 13:04:12 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497074#comment-13497074
] 

Dave Marion commented on ACCUMULO-708:
--------------------------------------

Josh,

  Please back out your change of setting dfs.datanode.data.dir.perm to 755. I believe this
issue is fixed in HDFS-1560. Instead, please change the hadoop-test dependency in start/pom.xml
to 1.1.0. I talked with Eric about changing the hadoop dependency from 0.20.205 to 1.1.0 for
Accumulo 1.5. I talked with Keith yesterday and I believe he is past the directory permission
issue, he is now running into another issue that has to do with the configuration of his computer.

Keith,

bq. •In AccumuloVFSClassLoader and AccumuloClassLoader the methods replaceEnvVars(), addUrl(),
findAccumuloURLs(), etc. look very similar. Are these methods just copies? If not, what is
the essence of the diffs?

 If I remember correctly, they are copies of methods in AccumuloClassLoader. I did not want
to extend AccumuloClassLoader as I do not know its lifetime.

bq. •Seems like unit test AccumuloContextClassLoaderTest would benefit from using two seprate
jars. The same jar is loaded into two different context. Seems like it would be better to
load two different jars with different classes. Then verify that each context contains only
the expected classes and nothing else.

 I was testing that the same jar/class was in fact being loaded by two different classloaders,
and were therefore different classes. I will add your test suggestions to my to-do list.

All,

 I believe that the discussion around which contexts are supported is a separate discussion.
I can think of several different scenarios in which contexts could be defined: per user, per
table, per scan session, per minc/majc session, per application, etc. Regarding the heirarchy
of the context classloader, I can see Keiths point above, and would also counter with a different
scenario. Say for example that I wanted to run different versions (api compatible of course)
of the Accumulo iterators on my table. The current setup would allow me to run a 1.5.0 tablet
server and 1.5.1 iterators on my table. I can do this because the context classloader for
my application is not a child of the system classloader. Changing the context classloader
to be a child of the system classloader is a very small change.

                
> Modify ClassLoader to support different applications / multi-tenancy
> --------------------------------------------------------------------
>
>                 Key: ACCUMULO-708
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-708
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: start
>            Reporter: Dave Marion
>            Assignee: Dave Marion
>              Labels: classloader
>             Fix For: 1.5.0
>
>         Attachments: ACCUMULO-708-1.patch
>
>   Original Estimate: 24h
>          Time Spent: 33h
>  Remaining Estimate: 0h
>
> I'd like to expand the current classloader to support loading classes from HDFS and different
application contexts. I'll be modifying the ticket as the idea matures.

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

Mime
View raw message