[
https://issues.apache.org/jira/browse/ZOOKEEPER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar reassigned ZOOKEEPER-303:
---
Assignee: Tom White
Bin scripts don't work on Mac
-
[
https://issues.apache.org/jira/browse/ZOOKEEPER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-303:
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672446#action_12672446
]
Mahadev konar commented on ZOOKEEPER-309:
-
can we include a test case for this
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
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
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?
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
You are right about the getData, and it was probably a wrong choice.
Both the getData and getChildren have an extra ACL check in the
FinalRequestProcessor. My question is pretty much this: shouldn't the
other request types have such a check as well? What if client B has
issued a setData()?
+1 to ben's suggestion. We can go ahead with 3.1.0 and make a 3.1.1 (given
that it wasn't working in the prev releases as well)...
mahadev
On 2/10/09 6:31 PM, Benjamin Reed br...@yahoo-inc.com wrote:
Chris's patch is very simple and it won't be hard to put some tests in. can we
plan a bug
10 matches
Mail list logo
