Is DynamicClassLoader necessary for client applications?

[Nick Dimiduk <nd...@gmail.com>]

Hi all,

It appears that as of HBASE-1936, we now require that client applications
have write access to hbase.local.dir. This is because ProtobufUtil
instantiates a DyanamicClassLoader as part of static initialization. This
classloader is used for instantiating Comparators, Filters, and Exceptions.

If this is indeed intended (ie, we want to support dynamically loading on
the client side for these objects), we need to update the documentation
accordingly.

I think this is in fact not the intention for application ("edge") clients.
My supposition is that a client application will explicitly provide their
own dependencies and they aren't loading anything from
hbase.dynamic.jars.dir.

It is probably necessary for clients instantiated on a RS though.

What say you? Is this a documentation issue, or should be attempt to
disentangle the DynamicClassLoader from client-side use?

Thanks,
Nick

Re: Is DynamicClassLoader necessary for client applications?

[Nick Dimiduk <nd...@gmail.com>]

Thanks. I opened HBASE-9374.


On Wed, Aug 28, 2013 at 4:49 PM, Nick Dimiduk <nd...@gmail.com> wrote:

> On Tue, Aug 27, 2013 at 11:09 PM, Stack <st...@duboce.net> wrote:
>
>> what do we gain if we go to the trouble distinguishing
>> true clients from clients used by hbase servers internally (even for
>> clients used internally by servers, why would we want these fellas doing
>> dynamic loading out of an hbase.local.dir)?
>>
>
> I was originally thinking there would be a need to support dynamic loading
> for RS-side clients who want to invoke a coprocessor endpoint. I'm now
> thinking that's unnecessary because those clients are probably instantiated
> out of a classloader which provides those endpoint definitions anyway.
>

Re: Is DynamicClassLoader necessary for client applications?

[Nick Dimiduk <nd...@gmail.com>]

On Tue, Aug 27, 2013 at 11:09 PM, Stack <st...@duboce.net> wrote:

> what do we gain if we go to the trouble distinguishing
> true clients from clients used by hbase servers internally (even for
> clients used internally by servers, why would we want these fellas doing
> dynamic loading out of an hbase.local.dir)?
>

I was originally thinking there would be a need to support dynamic loading
for RS-side clients who want to invoke a coprocessor endpoint. I'm now
thinking that's unnecessary because those clients are probably instantiated
out of a classloader which provides those endpoint definitions anyway.

Re: Is DynamicClassLoader necessary for client applications?

[Stack <st...@duboce.net>]

On Tue, Aug 27, 2013 at 11:17 AM, Nick Dimiduk <nd...@gmail.com> wrote:

>
> What say you? Is this a documentation issue, or should be attempt to
> disentangle the DynamicClassLoader from client-side use?
>

Sounds like undoing client requiring write access on hbase.local.dir would
be what we want but what do we gain if we go to the trouble distinguishing
true clients from clients used by hbase servers internally (even for
clients used internally by servers, why would we want these fellas doing
dynamic loading out of an hbase.local.dir)?

Thanks Nick,
St.Ack