Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of adragomi@adobe.com designates
 64.18.1.181 as permitted sender)
From: Andrei Dragomir <adragomi@adobe.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Date: Sat, 3 Dec 2011 06:00:06 +0000
Subject: Re: Coprocessors dynamic jar loading and coprocessorExec
Thread-Topic: Coprocessors dynamic jar loading and coprocessorExec
Thread-Index: AcyxgNDvNdB+l33jTOiEzYnaDK8C6g==
Message-ID: <CAFF8689.216FD%adragomi@adobe.com>
In-Reply-To: 
 <CALte62yUyM=TUQRb273cf_8WX9jWPP1sF5qx4eFRPDwW+x924w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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,=20
  Andrei.=20

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 =3D=20
>>(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.
>>
>>