Search Hadoop and all its sub project:

Switch to Threaded View
Subject: 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 <
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB