Did you try throwing CoprocessorException or making your custom exception a subclass of it? These should be carried through to the client.
Yes, for exceptions outside of this hierarchy, there is no way to know if the exception is recoverable or not, so the safe route is chosen and either the regionserver will abort or the coprocessor will be unloaded, depending on configuration. On Fri, Jan 27, 2017 at 12:55 AM Steen Manniche <[email protected]> wrote: > We have been using coprocessors to create secondary indexes as well as > doing some sanity checks on incoming data. > > Especially in the last case, we planned to use the prePut event to reject > Puts to hbase that did not pass our sanity checks for incoming data. I had > expected being able to signal the client ingesting data into hbase via > throwing a custom exception, but learned that the regionserver the > coprocessor is installed on basically only have two options in the face of > a coprocessor throwing an exception: unloading the coprocessor or shutting > down. > > This behaviour surprises me since coprocessors almost by definition contain > application logic, and exceptions are a standard way of signalling in > application logic. Are there any plans to make the signal handling work > better wrt. clients in coprocessors? Or have I simply misunderstood the > intention of coprocessors here? > > Thanks in advance and best regards, > Steen Manniche >
