You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Baiqiang Zhao <zb...@gmail.com> on 2021/07/02 06:35:44 UTC
[DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never expire,
the same as CF TTL
Hi,
For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1” will
expire immediately. In HBASE-26056, I tried to unify the meaning of cell
TTL and CF TTL on the value of -1, both mean never expire.
This is a behavior change. Maybe will break some users usage. However,
setting it to -1 will immediately expires, and it doesn't make any sense. I
haven't thought of what kind of scene would be used in this way. So I want
to hear your opinions about this change.
Thanks.
Re: [DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never
expire, the same as CF TTL
Posted by Baiqiang Zhao <zb...@gmail.com>.
Thanks for the suggestion, will try to add additional checks on the server
side.
Nick Dimiduk <nd...@gmail.com> 于2021年7月8日周四 上午3:37写道：
> I agree that validation should happen on the server. We should not assume
> anything about the client in terms of correctness.
>
> On Wed, Jul 7, 2021 at 21:30 Andrew Purtell <an...@gmail.com>
> wrote:
>
> > I don’t have a strong opinion but servers can never fully trust clients.
> > The client can be altered. Maybe not by you/us. Typically the servers are
> > fully under your control and this is where you must apply service
> > protection, hence validity checks on the server side - regardless of what
> > the client does.
> >
> > > On Jul 7, 2021, at 2:23 AM, Baiqiang Zhao <zb...@gmail.com> wrote:
> > >
> > > Thanks Reid and Andrew!
> > >
> > > Agree to reject negative TTL directly on the write path, because
> negative
> > > TTL is invalid.
> > > The point of divergence is whether this check is on the client side or
> on
> > > the server side.
> > >
> > > I simply think it is easier to check and throw the exception directly
> on
> > > the client side, and there is no additional pressure on the server.
> > > If the check is on the server side, it will increase the pressure on
> the
> > > RegionServer (although the pressure is small).
> > >
> > > I prefer to check and throw exceptions on the client side.
> > >
> > > Andrew Purtell <an...@gmail.com> 于2021年7月4日周日 上午3:16写道：
> > >
> > >> We can also reject the request on the server side with an extra
> > >> validation. A negative TTL is not valid in any case.
> > >>
> > >>>> On Jul 3, 2021, at 5:35 AM, Reid Chan <re...@gmail.com>
> wrote:
> > >>>
> > >>> The default FOREVER is LONG.MAX, quite long enough.
> > >>>
> > >>> I checked the JIRA. The simplest fix is to ban setting -1 from the
> > client
> > >>> side by raising an exception, meanwhile we could improve the method
> > docs.
> > >>>
> > >>> I'm not a fan of changing the semantics of FOREVER, -1.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On Fri, Jul 2, 2021 at 2:36 PM Baiqiang Zhao <zb...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1”
> will
> > >>>> expire immediately. In HBASE-26056, I tried to unify the meaning of
> > cell
> > >>>> TTL and CF TTL on the value of -1, both mean never expire.
> > >>>>
> > >>>> This is a behavior change. Maybe will break some users usage.
> However,
> > >>>> setting it to -1 will immediately expires, and it doesn't make any
> > >> sense. I
> > >>>> haven't thought of what kind of scene would be used in this way. So
> I
> > >> want
> > >>>> to hear your opinions about this change.
> > >>>>
> > >>>> Thanks.
> > >>>>
> > >>
> >
>
Re: [DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never
expire, the same as CF TTL
Posted by Nick Dimiduk <nd...@gmail.com>.
I agree that validation should happen on the server. We should not assume
anything about the client in terms of correctness.
On Wed, Jul 7, 2021 at 21:30 Andrew Purtell <an...@gmail.com>
wrote:
> I don’t have a strong opinion but servers can never fully trust clients.
> The client can be altered. Maybe not by you/us. Typically the servers are
> fully under your control and this is where you must apply service
> protection, hence validity checks on the server side - regardless of what
> the client does.
>
> > On Jul 7, 2021, at 2:23 AM, Baiqiang Zhao <zb...@gmail.com> wrote:
> >
> > Thanks Reid and Andrew!
> >
> > Agree to reject negative TTL directly on the write path, because negative
> > TTL is invalid.
> > The point of divergence is whether this check is on the client side or on
> > the server side.
> >
> > I simply think it is easier to check and throw the exception directly on
> > the client side, and there is no additional pressure on the server.
> > If the check is on the server side, it will increase the pressure on the
> > RegionServer (although the pressure is small).
> >
> > I prefer to check and throw exceptions on the client side.
> >
> > Andrew Purtell <an...@gmail.com> 于2021年7月4日周日 上午3:16写道：
> >
> >> We can also reject the request on the server side with an extra
> >> validation. A negative TTL is not valid in any case.
> >>
> >>>> On Jul 3, 2021, at 5:35 AM, Reid Chan <re...@gmail.com> wrote:
> >>>
> >>> The default FOREVER is LONG.MAX, quite long enough.
> >>>
> >>> I checked the JIRA. The simplest fix is to ban setting -1 from the
> client
> >>> side by raising an exception, meanwhile we could improve the method
> docs.
> >>>
> >>> I'm not a fan of changing the semantics of FOREVER, -1.
> >>>
> >>>
> >>>
> >>>
> >>>> On Fri, Jul 2, 2021 at 2:36 PM Baiqiang Zhao <zb...@gmail.com>
> >> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1” will
> >>>> expire immediately. In HBASE-26056, I tried to unify the meaning of
> cell
> >>>> TTL and CF TTL on the value of -1, both mean never expire.
> >>>>
> >>>> This is a behavior change. Maybe will break some users usage. However,
> >>>> setting it to -1 will immediately expires, and it doesn't make any
> >> sense. I
> >>>> haven't thought of what kind of scene would be used in this way. So I
> >> want
> >>>> to hear your opinions about this change.
> >>>>
> >>>> Thanks.
> >>>>
> >>
>
Re: [DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never expire, the same as CF TTL
Posted by Andrew Purtell <an...@gmail.com>.
I don’t have a strong opinion but servers can never fully trust clients. The client can be altered. Maybe not by you/us. Typically the servers are fully under your control and this is where you must apply service protection, hence validity checks on the server side - regardless of what the client does.
> On Jul 7, 2021, at 2:23 AM, Baiqiang Zhao <zb...@gmail.com> wrote:
>
> Thanks Reid and Andrew!
>
> Agree to reject negative TTL directly on the write path, because negative
> TTL is invalid.
> The point of divergence is whether this check is on the client side or on
> the server side.
>
> I simply think it is easier to check and throw the exception directly on
> the client side, and there is no additional pressure on the server.
> If the check is on the server side, it will increase the pressure on the
> RegionServer (although the pressure is small).
>
> I prefer to check and throw exceptions on the client side.
>
> Andrew Purtell <an...@gmail.com> 于2021年7月4日周日 上午3:16写道：
>
>> We can also reject the request on the server side with an extra
>> validation. A negative TTL is not valid in any case.
>>
>>>> On Jul 3, 2021, at 5:35 AM, Reid Chan <re...@gmail.com> wrote:
>>>
>>> The default FOREVER is LONG.MAX, quite long enough.
>>>
>>> I checked the JIRA. The simplest fix is to ban setting -1 from the client
>>> side by raising an exception, meanwhile we could improve the method docs.
>>>
>>> I'm not a fan of changing the semantics of FOREVER, -1.
>>>
>>>
>>>
>>>
>>>> On Fri, Jul 2, 2021 at 2:36 PM Baiqiang Zhao <zb...@gmail.com>
>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1” will
>>>> expire immediately. In HBASE-26056, I tried to unify the meaning of cell
>>>> TTL and CF TTL on the value of -1, both mean never expire.
>>>>
>>>> This is a behavior change. Maybe will break some users usage. However,
>>>> setting it to -1 will immediately expires, and it doesn't make any
>> sense. I
>>>> haven't thought of what kind of scene would be used in this way. So I
>> want
>>>> to hear your opinions about this change.
>>>>
>>>> Thanks.
>>>>
>>
Re: [DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never
expire, the same as CF TTL
Posted by Baiqiang Zhao <zb...@gmail.com>.
Thanks Reid and Andrew!
Agree to reject negative TTL directly on the write path, because negative
TTL is invalid.
The point of divergence is whether this check is on the client side or on
the server side.
I simply think it is easier to check and throw the exception directly on
the client side, and there is no additional pressure on the server.
If the check is on the server side, it will increase the pressure on the
RegionServer (although the pressure is small).
I prefer to check and throw exceptions on the client side.
Andrew Purtell <an...@gmail.com> 于2021年7月4日周日 上午3:16写道：
> We can also reject the request on the server side with an extra
> validation. A negative TTL is not valid in any case.
>
> > On Jul 3, 2021, at 5:35 AM, Reid Chan <re...@gmail.com> wrote:
> >
> > The default FOREVER is LONG.MAX, quite long enough.
> >
> > I checked the JIRA. The simplest fix is to ban setting -1 from the client
> > side by raising an exception, meanwhile we could improve the method docs.
> >
> > I'm not a fan of changing the semantics of FOREVER, -1.
> >
> >
> >
> >
> >> On Fri, Jul 2, 2021 at 2:36 PM Baiqiang Zhao <zb...@gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1” will
> >> expire immediately. In HBASE-26056, I tried to unify the meaning of cell
> >> TTL and CF TTL on the value of -1, both mean never expire.
> >>
> >> This is a behavior change. Maybe will break some users usage. However,
> >> setting it to -1 will immediately expires, and it doesn't make any
> sense. I
> >> haven't thought of what kind of scene would be used in this way. So I
> want
> >> to hear your opinions about this change.
> >>
> >> Thanks.
> >>
>
Re: [DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never expire, the same as CF TTL
Posted by Andrew Purtell <an...@gmail.com>.
We can also reject the request on the server side with an extra validation. A negative TTL is not valid in any case.
> On Jul 3, 2021, at 5:35 AM, Reid Chan <re...@gmail.com> wrote:
>
> The default FOREVER is LONG.MAX, quite long enough.
>
> I checked the JIRA. The simplest fix is to ban setting -1 from the client
> side by raising an exception, meanwhile we could improve the method docs.
>
> I'm not a fan of changing the semantics of FOREVER, -1.
>
>
>
>
>> On Fri, Jul 2, 2021 at 2:36 PM Baiqiang Zhao <zb...@gmail.com> wrote:
>>
>> Hi,
>>
>> For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1” will
>> expire immediately. In HBASE-26056, I tried to unify the meaning of cell
>> TTL and CF TTL on the value of -1, both mean never expire.
>>
>> This is a behavior change. Maybe will break some users usage. However,
>> setting it to -1 will immediately expires, and it doesn't make any sense. I
>> haven't thought of what kind of scene would be used in this way. So I want
>> to hear your opinions about this change.
>>
>> Thanks.
>>
Re: [DISCUSS] HBASE-26056 Cell TTL set to -1 should mean never
expire, the same as CF TTL
Posted by Reid Chan <re...@gmail.com>.
The default FOREVER is LONG.MAX, quite long enough.
I checked the JIRA. The simplest fix is to ban setting -1 from the client
side by raising an exception, meanwhile we could improve the method docs.
I'm not a fan of changing the semantics of FOREVER, -1.
On Fri, Jul 2, 2021 at 2:36 PM Baiqiang Zhao <zb...@gmail.com> wrote:
> Hi,
>
> For CF TTL, “-1” means it will not expire. But for Cell TTL, “-1” will
> expire immediately. In HBASE-26056, I tried to unify the meaning of cell
> TTL and CF TTL on the value of -1, both mean never expire.
>
> This is a behavior change. Maybe will break some users usage. However,
> setting it to -1 will immediately expires, and it doesn't make any sense. I
> haven't thought of what kind of scene would be used in this way. So I want
> to hear your opinions about this change.
>
> Thanks.
>