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 <[email protected]> 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. > >
