[
https://issues.apache.org/jira/browse/HBASE-9941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14121569#comment-14121569
]
Vladimir Rodionov commented on HBASE-9941:
------------------------------------------
The additional observed overhead is explained here:
https://bugs.openjdk.java.net/browse/JDK-6642881?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel
Class.getClassLoader() is expensive op because of JNI nature.
CoprocessorHost.Environment
{code}
@Override
public ClassLoader getClassLoader() {
return impl.getClass().getClassLoader();
}
{code}
does not do any attempts to cache class loader instance. I think it is safe to
cache it. Correct me if I am wrong.
> The context ClassLoader isn't set while calling into a coprocessor
> ------------------------------------------------------------------
>
> Key: HBASE-9941
> URL: https://issues.apache.org/jira/browse/HBASE-9941
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
> Affects Versions: 0.96.0
> Reporter: Benoit Sigoure
> Assignee: Andrew Purtell
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 9941.patch, 9941.patch, 9941.patch, 9941.patch,
> 9941.patch
>
>
> Whenever one of the methods of a coprocessor is invoked, the context
> {{ClassLoader}} isn't set to be the {{CoprocessorClassLoader}}. It's only
> set properly when calling the coprocessor's {{start}} method. This means
> that if the coprocessor code attempts to load classes using the context
> {{ClassLoader}}, it will fail to find the classes it's looking for.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
