hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Coprocessors dynamic jar loading and coprocessorExec
Date Fri, 02 Dec 2011 18:42:08 GMT
Setting a table coprocessor from the shell is a new feature.
Are you using 0.92 ?

You are welcome to create a JIRA and publish your patch.
On Fri, Dec 2, 2011 at 5:06 PM, Andrei Dragomir <adragomi@adobe.com> wrote:

> I'm running into a bit of an issue with table coprocessors loaded
> dynamically.
> I'm setting a table coprocessor from the shell (dynamic loading),
> everything works fine. The coprocessor is not a RegionObserver /
> WALObserver, it just has a custom method.
> I see in the logs the coprocessor class being loaded correctly, it is
> displayed in the web interface, everything seems to be fine.
> When I try to call the custom method, the call throws an error. I tracked
> it down to o.a.h.h.client.coprocessor.Exec, which tries to "eagerly"
> deserialize the call. The problem is that in the context where the Exec
> call is running, there is no coprocessor protocol class loaded (it's
> dynamic, not from the configuration), so the call to get the class fails:
> protocol = (Class<CoprocessorProtocol>)conf.getClassByName(protocolName);
> I'm just trying to understand whether this is by design, or if it's a
> missing feature.
> I have a patch that passes the coprocessor class as String, and the actual
> instantiation is done in the HRegion instance, where we actually have the
> coprocessor class. I can create an issue and attach it.
> Thanks,
>  Andrei.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message