Cyrille Artho commented on ZOOKEEPER-2439:

I think the idea of "throttling" as such is good, but if it has a timeout, then 
the same bug may reappear, just much more rarely.

If {{SyncRequestsProcessor}} propagates changes to other servers, I think it 
may be better to check access permission at the earliest stage. Otherwise it 
may become necessary to undo changes.

>From that point of view, throttling pending requests of the /same/ session 
>until all other pending ACL operations are done, seems inevitable. Requests of 
>/other/ sessions do not have to be throttled as it does not really matter if 
>other requests "win" because of a faster network or because of thread 

If throttled requests originate from the same client session as pending ACL 
requests, a timeout seems unnecessary. Furthermore, the use of static variables 
looks very dangerous to me, as this may mix up multiple unrelated ACL requests 
(from different sessions).

If we throttle only requests of the same session, aren't those using the same 
instance of {{PrepRequestProcessor}}? That would make static fields (and 
timeouts) unnecessary.

> The order of asynchronous setACL is not correct.
> ------------------------------------------------
>                 Key: ZOOKEEPER-2439
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
>             Project: ZooKeeper
>          Issue Type: Bug
>    Affects Versions: 3.4.8, 3.5.1
>         Environment: Linux Ubuntu
> Mac OS X
>            Reporter: Kazuaki Banzai
>              Labels: acl
>         Attachments: ZOOKEEPER-2439-WIP.patch, ZOOKEEPER-2439.patch
> Within a given client connection, the execution of commands on the ZooKeeper 
> server is always ordered, as both synchronous and asynchronous commands are 
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a 
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE another API is called, asynchronous 
> setACL is applied AFTER another API.
> For example, if a client calls
> (1) asynchronous setACL to remove all permissions of node "/" and
> (2) synchronous create to create node "/a",
> synchronous create should fail, but it succeeds on Ubuntu.
> (We can see all permissions of node "/" are removed when the client calls 
> getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL 
> between (1) and (2), the synchronous case works correctly but the 
> asynchronous case still produces the bug.)
> The attached unit test reproduces this scenario. It fails on Linux Ubuntu but 
> succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test 
> sometimes fails as well but only rarely.

This message was sent by Atlassian JIRA

Reply via email to