Re: Are coprocessor really bad?
I think a misunderstanding of what we want to accomplish is the issue.
We designed coprocessors to function as in-server extensions for HBase core
developers and system integrators. Specifically, we wanted to flexibly
extend server functions through composition rather than use the brittle and
inflexible class inheritance way which was done up to that point. I think
you can look at our security coprocessors as the canonical example of
extensions as coprocessor done successfully. There is also Apache Phoenix.
There are also a few coprocessor success stories at every Hadoop or HBase
conference I have been at since they went in.
Explicitly, we have a non-goal of trying to be OSGi-type-friendly for
random user applications. Frankly, coprocessors are not meant for loading
*and* unloading extensions. They are meant for loading extensions over the
lifetime of the regionserver. There are a lot of corner cases we just don't
have to care about and spend time on if coprocessor extensions effectively
have the same lifecycle as the RegionServer. They live within the
RegionServer process and can do just about anything, so can we really
guarantee any state changes they might make deliberately or through
implementation bugs can be cleaned up upon unload? No.
On Sat, Mar 15, 2014 at 4:16 PM, Jean-Marc Spaggiari <
[EMAIL PROTECTED]> wrote:
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)