0c883a23c5
------------------------------------------------------ TL;DR ------------------------------------------------------ We are moving from Inheritence - Observer *is* Coprocessor - FooService *is* CoprocessorService To Composition - Coprocessor *has* Observer - Coprocessor *has* Service ------------------------------------------------------ Design Changes ------------------------------------------------------ - Adds four new interfaces - MasterCoprocessor, RegionCoprocessor, RegionServierCoprocessor, WALCoprocessor - These new *Coprocessor interfaces have a get*Observer() function for each observer type supported by them. - Added Coprocessor#getService() to base interface. All extending *Coprocessor interfaces will get it from the base interface. - Added BulkLoadObserver hooks to RegionCoprocessorHost instad of SecureBulkLoadManager doing its own trickery. - CoprocessorHost#find*() fuctions: Too many testing hooks digging into CP internals. Deleted if can, else marked @VisibleForTesting. ------------------------------------------------------ Backward Compatibility ------------------------------------------------------ - Old coprocessors implementing *Observer won't get loaded (no backward compatibility guarantees). - Third party coprocessors only implementing Coprocessor will not get loaded (just like Observers). - Old coprocessors implementing CoprocessorService (for master/region host) /SingletonCoprocessorService (for RegionServer host) will continue to work with 2.0. - Added test to ensure backward compatibility of CoprocessorService/SingletonCoprocessorService - Note that if a coprocessor implements both observer and service in same class, its service component will continue to work but it's observer component won't work. ------------------------------------------------------ Notes ------------------------------------------------------ Did a side-by-side comparison of CPs in master and after patch. These coprocessors which were just CoprocessorService earlier, needed a home in some coprocessor in new design. For most it was clear since they were using a particular type of environment. Some were tricky. - JMXListener - MasterCoprocessor and RSCoprocessor (because jmx listener makes sense for processes?) - RSGroupAdminEndpoint --> MasterCP - VisibilityController -> MasterCP and RegionCP These were converted to RegionCoprocessor because they were using RegionCoprocessorEnvironment which can only come from a RegionCPHost. - AggregateImplementation - BaseRowProcessorEndpoint - BulkDeleteEndpoint - Export - RefreshHFilesEndpoint - RowCountEndpoint - MultiRowMutationEndpoint - SecureBulkLoadEndpoint - TokenProvider Change-Id: I813145f2bc11815f52ac703563b879962c249764 |
||
|---|---|---|
| .. | ||
| src | ||
| README.txt | ||
| pom.xml | ||
README.txt
ON PROTOBUFS
This maven module has protobuf definition files ('.protos') used by hbase
Coprocessor Endpoints that ship with hbase core including tests. Coprocessor
Endpoints are meant to be standalone, independent code not reliant on hbase
internals. They define their Service using protobuf. The protobuf version
they use can be distinct from that used by HBase internally since HBase started
shading its protobuf references. Endpoints have no access to the shaded protobuf
hbase uses. They do have access to the content of hbase-protocol -- the
.protos found in here -- but avoid using as much of this as you can as it is
liable to change.
Generation of java files from protobuf .proto files included here is done as
part of the build.