Thanks Alicia. I copied your comment to HBASE-12787 On Tue, Dec 30, 2014 at 4:36 PM, Alicia Shu <[email protected]> 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 <[email protected]> > 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 > > <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > > 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 < > > [email protected]> > > >>> 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. > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
