'Repurpose' might not be the way I would put it. Coprocessors were and are a means for internal server extension by mixin. The original problem we solved was needing to subclass HRegionServer and other classes to extend core HBase functions, but having more than one otherwise orthogonal extension that users want to use. Now we can mix in multiple extensions with a framework that has some simple rules for cooperation between the extensions.
We return to the earlier state of affairs with modules. Sure, we can plug in an alternate behavior with a module that subclasses and extends the default, say flush strategy, but we can't then instantiate multiple modules into the same slot, both subclassing the same base but doing different things. > On Feb 11, 2014, at 11:09 AM, Enis Söztutar <enis....@gmail.com> wrote: > > This is good discussion, > > I mentioned this in phoenix-dev that we need to repurpose coprocessors, and > just give them put / get kind of injection points, but not allow > co-processors to tap into log / compaction, etc. Those will be better > served by explicitly defined plugins (like the recent StorageEngine, HLog, > etc) that we explicitly allow injecting code with some API stability > (though probably still evolving at a fast pace). > > It would be good to have an idea of what classes / methods, phoenix and > similar depend on HBase right now. > > Enis > > > On Mon, Feb 10, 2014 at 6:04 PM, Jeffrey Zhong <jzh...@hortonworks.com>wrote: > >> >> We need to revisit which interfaces should be marked as real "private" >> because coprocessors allow custom applications to accesses internal >> states. Current private interface such as KeyValue, WALEdit, Hregion, >> HLogKey, Store etc is may used by custom coprocessor applications so any >> public method signature change in those "private" interfaces possibliy >> breaks custom coprocessor implementations. >> >> -Jeffrey >> >>> On 2/10/14 4:59 PM, "lars hofhansl" <la...@apache.org> wrote: >>> >>> True. But we can clearly annotate what is public and what is not. >>> In HRegion we'd have to do it per method. It's probably easier to extract >>> the public interface out into a Interface. (similar to Store and HStore) >>> HBASE-4207 solves a slightly different problem. Here I want to have >>> access to some HBase internals for performance, but I want to know what >>> is public and stable and what I should not touch (thinking about things >>> like Phoenix). >>> >>> >>> -- Lars >>> >>> >>> >>> ________________________________ >>> From: Andrew Purtell <apurt...@apache.org> >>> To: "dev@hbase.apache.org" <dev@hbase.apache.org> >>> Sent: Monday, February 10, 2014 4:46 PM >>> Subject: Re: DISCUSSION: 1.0.0 >>> >>> >>> On Mon, Feb 10, 2014 at 4:42 PM, lars hofhansl <la...@apache.org> wrote: >>> >>> >>>> + known coprocessor interfaces. For example right now a coprocessor can >>>> use everything on HRegion. We need to distill what's useful into an >>>> interface. >>> >>> >>> We started this with Environment and the HTable wrapper as an example of >>> how to wrap an interface for CPs. At the end of the day we can't stop a >>> coprocessor from accessing internal objects and calling their methods >>> directly until HBASE-4047. (Maybe that makes the 1.0 list?) >>> >>> Related, paring down the coprocessor interfaces to only intercept RPC >>> based >>> actions and move everything else to plugins. >>> >>> >>> >>> -- >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>> (via Tom White) >> >> >> >> -- >> CONFIDENTIALITY NOTICE >> NOTICE: This message is intended for the use of the individual or entity to >> which it is addressed and may contain information that is confidential, >> privileged and exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby notified that >> any printing, copying, dissemination, distribution, disclosure or >> forwarding of this communication is strictly prohibited. If you have >> received this communication in error, please contact the sender immediately >> and delete it from your system. Thank You. >>
