[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2439:
--
Attachment: ZOOKEEPER-2439-WIP.patch
I am attaching a crude and possible buggy stab at a solution.
My idea with this patch is just to *bootstrap* the discussion about possible
fixes, so *don't rely on it for being complete (what about multiop?), correct
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly
provided, for what's worth. :)
> 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
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2439: -- Assignee: (was: Edward Ribeiro) > 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.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 (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2439: -- Labels: acl (was: ) > 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 >Assignee: Edward Ribeiro > Labels: acl > Attachments: 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 (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kazuaki Banzai updated ZOOKEEPER-2439: -- Attachment: ZOOKEEPER-2439.patch This patch doesn't fix the bug. It includes a unit test only. > 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 > Attachments: 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 (v6.3.4#6332)
