Manos, in your scenario the getData will not succeed. the acl will be checked in the FinalRequestProcessor after the setAcl has passed through the final request processor. execution only happens in the final request processor and always happens in order.
the only way a getData will succeed after a setAcl succeeds if it is done on a lagging follower, but in that case it will see a lagging view of the system. consider the following: /foo has an open ACL client A: setAcl("/foo", restricted ACL); setData("/foo", new data); client B: getData("/foo"); no matter what happens, what the delays are, if B is faster or slower than A, client B will not see "new data". it will either pass the ACL check and see the old data or it will fail with a permission exception. ben ________________________________________ From: Manos Kapritsos [ma...@cs.utexas.edu] Sent: Tuesday, February 10, 2009 4:34 PM To: email@example.com Subject: Re: setACL semantics 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. Manos Mahadev Konar wrote: > Hi Manos, > 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 > getdata. > > > 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? > > mahadev > > > On 2/10/09 2:15 PM, "Manos Kapritsos" <ma...@cs.utexas.edu> wrote: > > >> Hi all, >> >> 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. 184.108.40.206) , 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 220.127.116.11. 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. >> >> Thank you, >> Manos >>