Mahadev, is it true that a lagging follower, participating in the
ensemble but not part of the quorum, would continue to respond to read
requests until it had received/processed the update from the leader?
Mahadev Konar wrote:
The accepting of a txn for being processed does not mean that the txn has
been accpeted by the quorum and has been applied to the quorum servers. So,
it is very much possible that one of the client changes an acl on a node and
the other client unauthorized to read (with respect to the change by
client1) reads the data before the acl change is propagated and accepted by
On 2/10/09 4:34 PM, "Manos Kapritsos" <ma...@cs.utexas.edu> wrote:
More or less, yes.
If the requests are from the same client, then you say that there will
not be a problem? I guess that is true if you always wait for the
response of the first request in order to execute the second. I am not
sure if that is a requirement for all Zookeeper client implementations.
As for two different clients (which was the case I was thinking about),
this seems to be a problem. I will agree that (if clients only have one
outstanding request) the two requests are concurrent and either order of
execution is considered to be acceptable, but it could be that two
different replicas receive the two requests in the same order, but
effectively execute them in a different order. In any case, it feels
wrong (at least to me) that a getData would succeed when a setACL that
prevents it has already been accepted to be processed.
Mahadev Konar wrote:
If the setAcl and getdata are from the same client then they are all
handled in order. So you would get an unauthroized exception when you do a
If two diff clients do setacl and getdata it might be that the getdata in
your case will succeed before the setacl returns on the first client.
Is that what you meant?
On 2/10/09 2:15 PM, "Manos Kapritsos" <ma...@cs.utexas.edu> wrote:
I have a question about the way setACL functions. It seems that the
PreRequestProcessor handles all kinds of requests the same, checks the
validity of the corresponding ACL, and enqueues them to Sync and Final
processors. Maybe I am missing something here, but this behaviour seems
weird. What if a setACL request comes, setting the ACL of a path (e.g. /
) to an IP (e.g. 188.8.131.52) , instead of its old value (e.g. World).
This request will pass the ACL check, and will be enqueued to be
processed by the next processors. Assume that the next request is a
getData("/") from an IP other than 184.108.40.206. If this request is
processed by the PreRequestProcessor before the setACL request is
processed by the FinalRequestProcessor, then it will pass the ACL check
(which it should not, since it came after the setACL request). It seems
that there is a race condition here that should not exist.
Let me know if this is actually the case or I am missing something. I am
using version 3.0.1 of the code.