Yes that is true.
mahadev
On 2/10/09 4:54 PM, "Patrick Hunt" <ph...@apache.org> wrote:
> 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?
>
> Patrick
>
> Mahadev Konar wrote:
>> HI Manos,
>>
>> 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
>> the quorum.
>>
>>
>> mahadev
>>
>>
>> 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.
>>>
>>> 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. 128.62.32.32) , 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 128.62.32.32. 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
>>>>>
>>
