Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028

[Ted Yu <yu...@gmail.com>]

In RSRpcServices, this (RSRpcServices) is passed to the create method:
       rpcSchedulerFactory.create(rs.conf, this));

RSRpcServices has reference to HRegionServer.

If RSRpcServices implements Abortable and delegates to regionServer,
RpcSchedulerFactory.create() would obtain the Abortable.

Just my two cents.

On Tue, Dec 30, 2014 at 4:36 PM, Alicia Shu <as...@hortonworks.com> wrote:

> If we would like to port this change to 0.98, another option is not
> changing RpcSchedulerFactory, but add a SET method for RpcScheduler that
> set the Abortable afterwards. Thus there will be no backward compatible
> issue. New code need to know to call the SET method. Old code will have a
> null abortable.
>
> Alicia
>
>
>
> On Tue, Dec 30, 2014 at 3:49 PM, James Taylor <ja...@apache.org>
> wrote:
>
> > bq. How many versions of HBase >= 0.98.10 do you think would need to
> > be binary compatible with 4.2.2?
> >
> > Good question. Do you have an opinion? We have a compatibility check
> > that we do on first connection to a cluster. Perhaps we can add a
> > check of Phoenix server version vs HBase server version to detect a
> > "breakage" scenario? In this case, we'd require the server-side
> > Phoenix version to be bumped up (maybe do this in 4.4?). We can doc it
> > as well, but it's been my experience that folks just don't read this.
> >
> > So perhaps have the reflection in place in HBase long enough for us to
> > get 4.4 out?
> >
> > Thanks for asking!
> >
> >     James
> >
> > On Tue, Dec 30, 2014 at 3:36 PM, Andrew Purtell
> > <an...@gmail.com> wrote:
> > > It would be a binary compatibility break unless we detect by reflection
> > that it's an older factory missing the new 'create' method and therefore
> > call the old one.
> > >
> > > We could add that.
> > >
> > > How many versions of HBase >= 0.98.10 do you think would need to be
> > binary compatible with 4.2.2?
> > >
> > >
> > >> On Dec 30, 2014, at 3:23 PM, James Taylor <ja...@apache.org>
> > wrote:
> > >>
> > >> Would our 4.2.2 binaries continue to work with releases of HBase
> > >> containing this change?
> > >>
> > >>
> > >>> On Tue, Dec 30, 2014 at 3:14 PM, Enis Söztutar <en...@gmail.com>
> > wrote:
> > >>> Thanks Andrew,
> > >>>
> > >>> Once HBASE-12028 is committed it should be easy enough to make the
> > changes
> > >>> in Phoenix to be able to compile with HBase versions pre or post
> > >>> HBASE-12028. But we need a PHOENIX issue for that.
> > >>>
> > >>> We should also make Abortable a LimitedPrivate it seems.
> > >>>
> > >>> Enis
> > >>>
> > >>> On Tue, Dec 30, 2014 at 2:49 PM, Andrew Purtell <
> > andrew.purtell@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> Hi Phoenix,
> > >>>>
> > >>>> Please see https://issues.apache.org/jira/browse/HBASE-12028
> > >>>>
> > >>>> The proposed change if committed into 0.98 branch would introduce a
> > new
> > >>>> 'create' method into the RpcSchedulerFactory interface that receives
> > an
> > >>>> Abortable as an additional parameter. Thus, the factory can pass
> this
> > on to
> > >>>> schedulers and workers and if something terrible happens in or to a
> > RPC
> > >>>> handler they can trigger a server abort. Due to a design oversight
> we
> > don't
> > >>>> otherwise have this capability. In my opinion it is important to fix
> > this
> > >>>> oversight. (Phoenix can also potentially make use of the Abortable
> for
> > >>>> fatal issues involving indexes.) Otherwise RPC handlers can silently
> > >>>> terminate upon receiving an unhandled throwable, potentially leaving
> > behind
> > >>>> bad state, certainly impacting performance and availability. However
> > >>>> because RpcSchedulerFactory is an interface any implementor will not
> > >>>> compile after this change, until updated.
> > >>>>
> > >>>> HBase could include this change in the next 0.98 release or not.
> > Please
> > >>>> advise.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>