[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636364#comment-16636364
]
Sakthi commented on HBASE-21225:
--------------------------------
[~elserj] thanks for your comments.
{quote}1. Why all of the modification/removal of existing tests?
{quote}
Actually I just added two test cases (to specifically test table/namespaces
with both quotas) and did just rename the previous ones to clearly specify that
those tests are to for drops with a single quota set on the entity. Looks like
the git diff shows previous test cases also to be modified (which is not the
case).
{quote}2. The purpose of the REMOVE => true entry is to denote that HBase
should remove the SpaceQuota when it writes that out. With this change, it
seems like you're leaving the REMOVE attribute in the protobuf message, but
completely ignoring it which is confusing.
{quote}
Yes, you are right.
{quote}IMO, the bug is that GlobalSettingsQuotaImpl is not correctly removing
the SpaceQuota when REMOVE is set to true.
{quote}
As of now, the bug seems to be in the following code peice:
{code:java}
if (throttleBuilder == null &&
(spaceBuilder == null || (spaceBuilder.hasRemove() &&
spaceBuilder.getRemove()))
&& bypassGlobals == null) {
return null;
}
{code}
When the throttlebuilder is not set and spacebuilder is set to remove, then
null is returned as the "merged" quota. But when throttlebuilder is set and
spacebuilder is set to remove, then it doesn't enter this condition and rather
passes over to this return statement:
{code:java}
return new GlobalQuotaSettingsImpl(
getUserName(), getTableName(), getNamespace(),
(throttleBuilder == null ? null : throttleBuilder.build()),
bypassGlobals,
(spaceBuilder == null ? null : spaceBuilder.build()));{code}
which just checks the "null" condition of spacebuilder and creates a new
GlobalQuotaSettingsImpl object that actually makes the "remove=>true" entry
stay in the table. Thinking along the lines to just fix how this works, instead
of just checking that spaceBuilder == null, we can also check if remove is set,
in this return statement.
{code:java}
return new GlobalQuotaSettingsImpl(
getUserName(), getTableName(), getNamespace(),
(throttleBuilder == null ? null : throttleBuilder.build()),
bypassGlobals,
(spaceBuilder == null || (spaceBuilder.hasRemove() &&
spaceBuilder.getRemove())? null : spaceBuilder.build()));{code}
This will produce the desired results.
{quote}Seems the logic I had initially written around an RPC and Space quota on
the same table/namespace is lacking. Does that make sense?{quote}
I will have to dig deeper. Will loop back with ideas, Josh.
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --------------------------------------------------------------------------------------------------
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
> Reporter: Sakthi
> Assignee: Sakthi
> Priority: Major
> Attachments: hbase-21225.master.001.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
> MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
> ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
