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. 

Reply via email to