hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Note breaking change on RegionObserver in hbase-2.0.0 (HBASE-15296 nice cleanup/refactor)
Date Thu, 14 Apr 2016 17:47:07 GMT
On Thu, Apr 14, 2016 at 10:43 AM, Matteo Bertozzi <theo.bertozzi@gmail.com>
wrote:

> If we change the coprocessor API we should consider a better
> naming/semantic. see HBASE-6992
>
>
​I also put a bunch of BS up on
https://issues.apache.org/jira/browse/HBASE-11125 once. ​It went off the
rails toward the end but I do like the idea of having a set of
occurrances/events upon which a CP user can register intent to observe
success or failure or intercept the operation.



> pre/postOperation doesn't do what the user want because the post is not
> really post.
> our execution in genereal is:
>
>    - pre operation (rpc thread)
>    - submit operation
>    - post operation (rpc thread)
>    - [pre operation (handler thread)]
>    - [post operation (handler thread)]
>
> for the user the pre and post should probably be the actual pre/post.
> which means pre (rpc thread) and post (handler thread).
>
> also, today on failure we don't have a post operation.
> which means that if someone does something in the pre operation there is no
> way to rollback that on failure.
> so, we should also add something like a "post operation failure".
>
>
>
> Matteo
>
>
> On Thu, Apr 14, 2016 at 10:25 AM, Stack <stack@duboce.net> wrote:
>
> > On Thu, Apr 14, 2016 at 8:59 AM, Andrew Purtell <apurtell@apache.org>
> > wrote:
> >
> > > I think a major version increment is when we've allowed ourselves
> leeway
> > to
> > > make breaking changes. If we were to do this though I'd like to see us
> > roll
> > > in as many as we can at once.
> > >
> > >
> > Agreed.
> >
> > I suppose I'm opening the flood gates so bring on your CP changes in time
> > for 2.0!
> >
> >
> >
> > > By the way, we are still sometimes breaking CPs without meaning to. I
> > think
> > > we messed up the RpcScheduler LimitedPrivate interface in 1.2 with
> > > HBASE-15146, which added a return type to RpcScheduler#dispatch, and
> > breaks
> > > Phoenix. Would you lot be interested in setting up a Jenkins job that
> > uses
> > > Phoenix to watch for accidental breakage? It's not comprehensive of
> > course
> > > but might be the closest available thing to it.
> > >
> > >
> > Probably no harm. Phoenix would be the canary. As long as someone looks
> at
> > it though? It'd be branch-1 job?
> >
> > St.Ack
> >
> >
> > >
> > >
> > > On Thu, Apr 14, 2016 at 8:50 AM, Stack <stack@duboce.net> wrote:
> > >
> > > > We cool w/ this?
> > > >
> > > > (I know we keep saying it over and over again that its fine to break
> > CPs
> > > > w/o deprecation but still uneasy doing the actual breakage.... hence
> > the
> > > > note here.)
> > > >
> > > > St.Ack
> > > >
> > >
> > >
> > >
> > > --
> > > 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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message