[
https://issues.apache.org/jira/browse/ZOOKEEPER-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-5074:
--------------------------------------
Labels: pull-request-available quota (was: quota)
> Quota checks ignore earlier operations in the same multi transaction
> --------------------------------------------------------------------
>
> Key: ZOOKEEPER-5074
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5074
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.9.5
> Reporter: Sahil Rajput
> Priority: Major
> Labels: pull-request-available, quota
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since ZOOKEEPER-3301, create and setData are validated against the quota
> limits in PrepRequestProcessor. The check compares the operation's effect
> against the quota stat node in the data tree. The operations of a multi
> transaction are all validated before any of them is applied, so the stat
> node does not yet reflect the earlier operations of the same transaction,
> and every operation is effectively checked in isolation.
> This has two visible consequences with 'zookeeper.enforceQuota=true':
> 1. A multi whose creates individually stay within a hard limit but
> together exceed it is admitted as a whole. For example, with
> countHardLimit=3 on /c (count 1 after setquota), a multi creating
> /c/1, /c/2 and /c/3 is accepted, leaving the subtree at count 4.
> 2. A multi that deletes as much as it creates is rejected when the
> subtree is at its hard limit. For example, with countHardLimit=2 on
> /replace holding one child, multi(delete /replace/old,
> create /replace/new) fails with QuotaExceededException even though
> the transaction does not change the node count. Deletes are not
> visible to the check at all, so the create is judged against the
> pre-transaction count.
> ZOOKEEPER-4219 fixed a related problem in the same code path (setData in
> a multi reading the node data through the outstanding ChangeRecord); this
> issue is about the quota arithmetic itself.
> I have a patch ready: PrepRequestProcessor accumulates the count and byte
> changes of the already-validated operations of the current request, per
> quota prefix, and checkQuota includes them in the comparison. Deletes
> contribute negative changes. The accumulator is only touched from the
> request processing thread and is reset at the start of each request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
