Sahil Rajput created ZOOKEEPER-5074:
---------------------------------------
Summary: 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
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)
