[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642882#comment-16642882
]
Sakthi commented on HBASE-21225:
--------------------------------
My observation:
{code:java}
....
QuotaSettings newQuota = QuotaSettings.buildFromProto(req);
GlobalQuotaSettingsImpl mergedQuota = currentQuota.merge(newQuota);
if (mergedQuota == null) {
quotaOps.delete();
} else {
quotaOps.update(mergedQuota);
}
....
{code}
The way to delete a quota is merging the new "delete" quota request with
whatever the current quotasettings the entity has and creating a new
GlobalQuotaSettingsImpl. While writing out data to the hbase:quota,
GlobalQuotaSettingsImpl.toQuotas() is called to create a Quotas object which is
converted to a byte array to update in the hbase:quota.
Few ways to handle the situation:
* As the "mergedQuota" is of type GlobalQuotaSettingsImpl and it's constructor
takes in Throttle.Builder & SpaceQuota.Builder as parameter, we can pass in
null values to both these parameters as and when required (whenever "remove" is
set?)
* Or, pass remove objects(i.e. spaceBuilder with only remove set to true) to
the constructor
## In the constructor of GlobalQuotaSettingsImpl, we can handle as to not set
"QuotaProtos.SpaceQuota spaceProto"data member, if "remove" objects are passed.
## Or, let the GlobalQuotaSettingsImpl be initialized with those objects. We
can later handle the case when we are trying to write out the data using
GlobalQuotaSettingsImpl.toQuotas().
{code:java}
protected Quotas toQuotas() {
QuotaProtos.Quotas.Builder builder = QuotaProtos.Quotas.newBuilder();
if (getThrottleProto() != null) {
builder.setThrottle(getThrottleProto());
}
....
if (getSpaceProto() != null) {
builder.setSpace(getSpaceProto());
}
return builder.build();
}
{code}
Here, along with the null checking we can also put the "remove set?" check as
well.
* Or, are we planning to wait little bit more till the end point where we are
actually writing the data? In that case, I wasn't able to figure out how would
we do that because I could see that we are using ".writeTo" of protobuf to
convert quotas into byte arrays. As here:
{code:java}
protected static byte[] quotasToData(final Quotas data) throws IOException {
ByteArrayOutputStream stream = new ByteArrayOutputStream();
stream.write(ProtobufMagic.PB_MAGIC);
data.writeTo(stream);
return stream.toByteArray();
}{code}
I prefer the first one, that way all the checking is contained in the merge
logic.
[~elserj], your thoughts, please?
> 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)
