HBASE-4120 deals with only the RPC prioritization parts. This cannot be implemented as a coprocessor.
> If it's completely a coprocessor, then it seems we should let it bake > on github and only incorporate in core if we find that a number of the > core HBase users are using it in production. The addition of the coprocessor framework is from my point of view a double edged sword. It can be a tool to clarify core and reduce maintenance burden on the community for various boutique functions. On the other hand it can be used to freeze further feature development and leave users who need such features out in the cold to go their own way or make a private fork. I've become aware of several private forks of HDFS and HBase. Too bad. A pooling of dev resources would have almost surely have been better. HBASE-4120 and successor issues are / will be an attempt to take what runs in production at Taobao and upstream it. They could just do a code drop on GitHub of what they have now. Would be much easier than reimplementing it as a coprocessor. However they have incentive here to give back to upstream, additional co-development with the community, for inclusion of their work in the distribution. What is the incentive if we want them to make the reimplementation effort only to then just drop that on GitHub? There are some cases where it would benefit all users to include coprocessor-based features in tree: Like security. Perhaps like constraints. Like the isolation/allocation stuff, for perhaps 0.94. Perhaps secondary indexing. In all of these cases, though the majority of the implementation is as coprocessor, there must be some changes to core -- to the coprocessor framework, generally -- to support it. A coprocessor can be included in the tree as a maven module. Without such inclusion, the rationale for not dropping the enabling logic in core may be lacking ... "oh, this just supports some GitHub thing". Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) ----- Original Message ----- > From: Todd Lipcon <t...@cloudera.com> > To: dev@hbase.apache.org > Cc: > Sent: Monday, December 12, 2011 4:03 PM > Subject: Re: Code review request for hbase-4120 table priority > > If it's completely a coprocessor, then it seems we should let it bake > on github and only incorporate in core if we find that a number of the > core HBase users are using it in production. Am I misunderstanding the > implementation? (haven't looked at the most recent patch) > > -Todd > > On Mon, Dec 12, 2011 at 3:50 PM, <yuzhih...@gmail.com> wrote: >> Waiting for review comments from other committers. >> The implementation is pluggable by using coprocessors. >> >> Cheers >> >> >> >> On Dec 12, 2011, at 5:43 PM, Stack <st...@duboce.net> wrote: >> >>> On Mon, Dec 12, 2011 at 6:43 AM, <yuzhih...@gmail.com> wrote: >>>> Hi, >>>> 4120 has gone through more than 20 revisions. >>>> >>>> Please provide your comments. >>>> >>>> I plan to integrate it this week. >>>> >>> >>> I'd suggest hold on commit until some other committers have had a >>> looksee. This is an important feature that we need to get right and >>> there is no need to rush it in. >>> >>> Thanks Ted (and thanks for the reviews so far), >>> St.Ack > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
