You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by Andrew Purtell <an...@gmail.com> on 2014/12/30 23:49:15 UTC
Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
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.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by James Taylor <ja...@apache.org>.
Thanks, Andrew. I filed PHOENIX-1569 as well.
On Tue, Dec 30, 2014 at 4:34 PM, Andrew Purtell <ap...@apache.org> wrote:
> Thanks for the feedback James. I filed HBASE-12787 in response.
>
> 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.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by James Taylor <ja...@apache.org>.
Thanks, Andrew. I filed PHOENIX-1569 as well.
On Tue, Dec 30, 2014 at 4:34 PM, Andrew Purtell <ap...@apache.org> wrote:
> Thanks for the feedback James. I filed HBASE-12787 in response.
>
> 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.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Andrew Purtell <ap...@apache.org>.
Thanks for the feedback James. I filed HBASE-12787 in response.
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.
> >>>>
> >>>>
> >>>>
> >>>>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by 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.
>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Andrew Purtell <ap...@apache.org>.
Thanks Alicia. I copied your comment to HBASE-12787
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.
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by 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.
>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Alicia Shu <as...@hortonworks.com>.
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.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Alicia Shu <as...@hortonworks.com>.
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.
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Andrew Purtell <ap...@apache.org>.
Thanks for the feedback James. I filed HBASE-12787 in response.
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.
> >>>>
> >>>>
> >>>>
> >>>>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by James Taylor <ja...@apache.org>.
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 <an...@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.
>>>>
>>>>
>>>>
>>>>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by James Taylor <ja...@apache.org>.
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 <an...@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.
>>>>
>>>>
>>>>
>>>>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Andrew Purtell <an...@gmail.com>.
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 <an...@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.
>>>
>>>
>>>
>>>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Andrew Purtell <an...@gmail.com>.
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 <an...@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.
>>>
>>>
>>>
>>>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by James Taylor <ja...@apache.org>.
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 <an...@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.
>>
>>
>>
>>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by James Taylor <ja...@apache.org>.
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 <an...@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.
>>
>>
>>
>>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Enis Söztutar <en...@gmail.com>.
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 <an...@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.
>
>
>
>
Re: Considering a RpcSchedulerFactory change in 0.98 for HBASE-12028
Posted by Enis Söztutar <en...@gmail.com>.
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 <an...@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.
>
>
>
>