hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Helmling (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3552) Coprocessors Are Unable To Load If RegionServer is Launched Using a Different Classloader than System Default
Date Tue, 22 Feb 2011 19:28:38 GMT

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

Gary Helmling commented on HBASE-3552:
--------------------------------------

I don't see any reason not to do #1.  Or rather, I don't see any reason we should be using
the system classloader in loadSystemCoprocessors() as opposed to the classloader used to load
CoprocessorHost.

Would it work to replace the lines in CoprocessorHost.loadSystemCoprocessors():
{quote}
      ClassLoader cl = ClassLoader.getSystemClassLoader();
      Thread.currentThread().setContextClassLoader(cl);
{quote}

with 
{quote}
      ClassLoader cl = this.getClass().getClassLoader();
      Thread.currentThread().setContextClassLoader(cl);
{quote}

This would then use the same ClassLoader used to run the region server, right?  And should
fix the problem?

Do you have a simple test case we can use?

> Coprocessors Are Unable To Load If RegionServer is Launched Using a Different Classloader
than System Default
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3552
>                 URL: https://issues.apache.org/jira/browse/HBASE-3552
>             Project: HBase
>          Issue Type: Bug
>          Components: coprocessors, regionserver
>    Affects Versions: 0.92.0
>         Environment: Ubuntu 10.10 x86_32
>            Reporter: Ed Kohlwey
>
> If a region server is launched in a context such that its classloader is different from
the system class loader, then the Class object used to represent the Coprocessor interface
of the coprocessor will be different than the Coprocessor Class object that is used by RegionCoprocessorHost.loadSystemCoprocessors()
.
> There's a few options that come to mind to fix this problem:
> 1. Remove the logic where loadSystemCoprocessors changes the context's ClassLoader back
to the system default classloader.
> 2. Remove the cast to Coprocessor in CoprocessorHost.load() and invoke methods via reflection.
> 3. Set the class loader back to the system default before launching any daemon threads.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message