Home | About | Sematext search-lucene.com search-hadoop.com
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
 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?
> 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)
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