You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stack <st...@duboce.net> on 2012/12/20 22:20:35 UTC
DISCUSSION: 0.96.0: Purge CoprocessorProtocol and all associated
parts of this jettisoned engine?
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
Re: DISCUSSION: 0.96.0: Purge CoprocessorProtocol and all associated
parts of this jettisoned engine?
Posted by Andrew Purtell <ap...@apache.org>.
I think it's good to get this out there again, it's going to be a big
change.
On Thu, Dec 20, 2012 at 3:40 PM, Stack <st...@duboce.net> wrote:
> 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 <ap...@apache.org>
> 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 <st...@duboce.net> 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)
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: DISCUSSION: 0.96.0: Purge CoprocessorProtocol and all associated
parts of this jettisoned engine?
Posted by Stack <st...@duboce.net>.
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 <ap...@apache.org> 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 <st...@duboce.net> 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)
>
Re: DISCUSSION: 0.96.0: Purge CoprocessorProtocol and all associated
parts of this jettisoned engine?
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <st...@duboce.net> 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)