hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alicia Shu <a...@hortonworks.com>
Subject Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Date Wed, 31 Dec 2014 00:36:28 GMT
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 <jamestaylor@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
> <andrew.purtell@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 <jamestaylor@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 <enis.soz@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.

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