commit 2a1f58ac4fdf4ed7cbfbe89662aa1a88a024762d
author maoling <maoling199210191@sina.com> Tue Jan 19 08:05:37 2021 +0000
committer Damien Diederen <ddiederen@apache.org> Tue Jan 19 08:07:30 2021 +0000
tree e5260223f51392485eb55f14126fb3136ec1381e
parent 1533380506162efb459a61caefdd3bf558099be7

ZOOKEEPER-3301: Enforce the quota limit

- Thanks for the original work from ZOOKEEPER-1383, ZOOKEEPER-2593, ZOOKEEPER-451, especially the work from ZOOKEEPER-1383 contributed by [Thawan Kooburat](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=thawan)(I also sign off his name in the commit message) which also implemented the very valuable throughput quota.In the further, we will also do this.
- `zookeeper.enforeQuota`. When enabled and the client exceeds the total bytes or children count hard quota under a znode, the server will reject the request and reply the client a `QuotaExceededException` by force. The default value is: false.
- the checkQuota involves the `create()` and `setData()` api, not including the `delete()`.
- When users set the quota which's less than the existing stats, we give a thoughtful warning info.
- the following code in the StatsTrack has a bad augmentability:

  >             if (split.length != 2) {
  >                 throw new IllegalArgumentException("invalid string " + stats);
  >             }

   we do a trick to solve it for the expansibility, but we will get a little strange quota info(`Output quota for /c2 count=-1,bytes=-1=;byteHardLimit=-1;countHardLimit=5`) when using `listquota`. some UTs has covered it.
- the logic about `checkQuota` should be put in the `PrepRequestProcessor`, other than `DataTree`.
  we will get the following two negative effects if putting `checkQuota` in the `DataTree`:
  - 1. When the write request has exceeded the quota, the corresponding transaction log will load into disk successfully.It's not good, although it has any data inconsistency issue, because when the server restart, so long as the transaction logs are applied in the same order, the exceeded nodes will not be applied into the state machine.
  - 2. the client will be blocking and waiting for the response, because when throwing `QuotaExceededException` in the the `DataTree`, the` rc.stat` will be `null` and `BinaryOutputArchive#writeRecord` will throw `NPE`.
  - 3. Overall, the pre-check about the write request should be done in the `PrepRequestProcessor`(at least before `SyncRequestProcessor`)(Look at an example from `checkACL()`)
- more detail in the [ZOOKEEPER-3301](https://issues.apache.org/jira/browse/ZOOKEEPER-3301).
- [Added in 2020-02-25] use `RateLogger` to replace `LOG` to avoid quota exceed logs flooding the disk
- A `TODO` improvement is: only users have admin permission can write to `/zookeeper/quota`(just like `/zookeeper/config`) to avoid some users' misoperation

Author: maoling <maoling199210191@sina.com>

Reviewers: Mate Szalay-Beko <symat@apache.org>, Damien Diederen <ddiederen@apache.org>, Enrico Olivelli <eolivelli@apache.org>, Michael Han <hanm@apache.org>

Closes #934 from maoling/ZOOKEEPER-3301

(cherry picked from commit 190a227aa9d4655ebfe6ba9f5c2da426da8c5d98)
Signed-off-by: Damien Diederen <ddiederen@apache.org>