hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Dragomir <adrag...@adobe.com>
Subject Re: Coprocessors dynamic jar loading and coprocessorExec
Date Sat, 03 Dec 2011 06:00:06 GMT
Yup, 0.92. However, I don't think it is linked to setting it from the
shell, or programmatically from java code (new HtableDescriptor....).
I am using a dynamically loaded coprocessor though, from HDFS.
The problem seems to be that the coprocessor protocol that I am using is
not available in the RPC server when deserializing the call. It does get
loaded in the RegionCoprocessorHost, and I fixed it by making a small
patch that passes the coprocessor full class name as String, and let it be
resolved in the Region exec call.

Thanks, 
  Andrei. 

On 12/2/11 8:42 PM, "Ted Yu" <yuzhihong@gmail.com> wrote:

>Andrei:
>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.
>>
>>


Mime
View raw message