Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> DISCUSSION: 0.96.0: Purge CoprocessorProtocol and all associated parts of this jettisoned engine?


Copy link to this message
-
Re: DISCUSSION: 0.96.0: Purge CoprocessorProtocol and all associated parts of this jettisoned engine?
Thanks Andrew.

I've actually messed up in that this issue has already been discussed back
in September and consensus was to go with purging CoprocessorProtocol [1
and 2].  Sorry for the noise.  Let me go  make a patch.

St.Ack

1.
http://mail-archives.apache.org/mod_mbox/hbase-dev/201209.mbox/%3CCADfYSXTvqEu3SifyWdZCi9kKPw1Hf9EoaKVGFOCbwRpSkdaCng%40mail.gmail.com%3E
2. https://issues.apache.org/jira/browse/HBASE-6895

On Thu, Dec 20, 2012 at 2:10 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> > We will have to support two very different underpinnings for an exotic
> though
> critical feature
>
> I think this means supporting CoprocessorProtocol based endpoint RPC in
> 0.94 and PB based endpoint RPC in 0.96+. If so then yes.
>
> Pro:
> + Normalizes interactions over RPC with HBase. Everything speaks protobufs.
>
> The fact is HBase 0.96 has a redesigned RPC stack, and coprocessor
> endpoints wrap RPC. This change is IMO a necessary consequence of other
> changes we have already decided upon and committed.
>
> I can help out with transitions from a 0.94 world to a 0.96+ one too.
>
>
> On Thu, Dec 20, 2012 at 1:20 PM, Stack <[EMAIL PROTECTED]> wrote:
>
> > Are folks down with purging CoprocessorProtocol in 0.96 and all of its
> > associated machinery?
> >
> > For example, Andrew Purtell says "I'd be +1 with dropping
> > CoprocessorProtocol from 0.96 and up, given all of the other (deliberate)
> > incompatibilities posed with RPC going from 0.94 to 0.96 and up." [2].
> >
> > CoprocessorProtocol is how we did dynamic endpoints before 0.96/trunk
> where
> > we are moving to protobuf'ing all rpc Interactions.  Dynamic endpoints
> are
> > now done using CoprocessorService where you define your endpoint as a
> > protobuf Service [1].
> >
> > Cons:
> > + Any current coprocessor dynamic endpoint will need to be refactored to
> > run on 0.96
> > + We will have to support two very different underpinnings for an exotic
> > though critical feature (We'd have to do this if we wanted to deprecate
> to
> > purge in another release)
> >
> > Pros:
> > + Purge a bunch of code.  Simplify RPC.  Save a bunch of effort making
> sure
> > both mechanisms work.  One, "cleaner" (though perhaps more verbose) way
> of
> > implementing dynamic endpoints.
> >
> > I'm in favor of purge without deprecation.  I've done a few convertions.
>  I
> > volunteer to help out anyone who needs to make the transition.
> >
> > St.Ack
> >
> >
> >
> >
> >
> > 1. https://issues.apache.org/jira/browse/HBASE-6789
> > 2. http://goo.gl/fSTLM
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>