[
https://issues.apache.org/jira/browse/HBASE-9941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13861856#comment-13861856
]
Andrew Purtell commented on HBASE-9941:
---------------------------------------
bq. Shouldn't we keep the catch (Throwable e) here, unless that is redundant
for some reason?
Good spotting, that appears to be a case where some text was accidentally
highlighted under the cursor before a paste. Let me check each call site for
those and get back with an updated patch.
bq. I see that preWALWrite() and postWALWrite() implementations are not doing
the handleCoprocessorThrowable() handling on unexpected Throwables. Can you
think of a reason WALCoprocessorHost should not do the same as others here?
No. I can try adding that in this patch, it's not too far out of scope, we are
updating every upcall invocation.
bq. In my 20m row filter-everything-at-the-server test, it'd add 1.4s
(20m*70ns) or about 20% runtime if there is at least RegionObserver registered
It also depends on the JVM. OpenJDK 7u45 on my test box has a difference of
~50ns.
> 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
>
> Attachments: 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.1.5#6160)
