[jira] Commented: (ZOOKEEPER-704) GSoC 2010: Read-Only Mode
[
https://issues.apache.org/jira/browse/ZOOKEEPER-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865465#action_12865465
]
Dave Wright commented on ZOOKEEPER-704:
---
This is a great idea, but I'm afraid there is a somewhat fundamental problem
with this concept.
What you want is if enough nodes go down that a quorum can't be formed (at
all), the remaining nodes go into read-only mode.
The problem is that if a partition occurs (say, a single server loses contact
with the rest of the cluster), but a quorum still exists, we want clients who
were connected to the partitioned server to re-connect to a server in the
majority. The current design allows for this by denying connections to minority
nodes, forcing clients to hunt for the majority. If we allow servers in the
minority to keep/accept connections, then clients will end up in read-only mode
when they could have simply reconnected to the majority.
It may be possible to accomplish the desired outcome with some client-side and
connection protocol changes. Specifically, a flag on the connection request
from the client that says allow read-only connections - if false, the server
will close the connection, allowing the client to hunt for a server in the
majority. Once a client has gone through all the servers in the list (and found
out that none are in the majority) it could flip the flag to true and connect
to any running servers in read-only mode. There is still the question of how to
get back out of read only mode (e.g. should we keep hunting in the background
for a majority, or just wait until the server we are connected to re-forms a
quorum).
GSoC 2010: Read-Only Mode
-
Key: ZOOKEEPER-704
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-704
Project: Zookeeper
Issue Type: Wish
Reporter: Henry Robinson
Read-only mode
Possible Mentor
Henry Robinson (henry at apache dot org)
Requirements
Java and TCP/IP networking
Description
When a ZooKeeper server loses contact with over half of the other servers in
an ensemble ('loses a quorum'), it stops responding to client requests
because it cannot guarantee that writes will get processed correctly. For
some applications, it would be beneficial if a server still responded to read
requests when the quorum is lost, but caused an error condition when a write
request was attempted.
This project would implement a 'read-only' mode for ZooKeeper servers (maybe
only for Observers) that allowed read requests to be served as long as the
client can contact a server.
This is a great project for getting really hands-on with the internals of
ZooKeeper - you must be comfortable with Java and networking otherwise you'll
have a hard time coming up to speed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-704) GSoC 2010: Read-Only Mode
[
https://issues.apache.org/jira/browse/ZOOKEEPER-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865470#action_12865470
]
Sergey Doroshenko commented on ZOOKEEPER-704:
-
Dave, thanks for feedback,
Did you check http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode ?
Approach described there is similar to what you've proposed: make server
distinguish read-only and usual clients.
However, I was thinking that r-o client should go to read-only mode right after
server it's tied to is partitioned, without trying to reconnect to majority.
But your idea that client should try all servers first is definitely a better
option.
Also I think current behavior of ZooKeeper client should remain unchanged.
I mean, there should be either new class for r-o client, or new functionality
in current client which is explicitly triggered say by a flag passed to ctor.
The idea is not to break code for current users.
GSoC 2010: Read-Only Mode
-
Key: ZOOKEEPER-704
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-704
Project: Zookeeper
Issue Type: Wish
Reporter: Henry Robinson
Read-only mode
Possible Mentor
Henry Robinson (henry at apache dot org)
Requirements
Java and TCP/IP networking
Description
When a ZooKeeper server loses contact with over half of the other servers in
an ensemble ('loses a quorum'), it stops responding to client requests
because it cannot guarantee that writes will get processed correctly. For
some applications, it would be beneficial if a server still responded to read
requests when the quorum is lost, but caused an error condition when a write
request was attempted.
This project would implement a 'read-only' mode for ZooKeeper servers (maybe
only for Observers) that allowed read requests to be served as long as the
client can contact a server.
This is a great project for getting really hands-on with the internals of
ZooKeeper - you must be comfortable with Java and networking otherwise you'll
have a hard time coming up to speed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865523#action_12865523 ] Chris K Wensel commented on ZOOKEEPER-679: -- actually, I went ahead and threw this on github http://github.com/cwensel/ztree the tests don't compile or run as they depend on un-jarred zk test classes, but there is a build file that will create a simple jar. Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865526#action_12865526 ] Aaron Crow commented on ZOOKEEPER-679: -- Hi Chris, my apologies, I haven't had much time to continue with this patch. I kind of got held up by the combination of limited time, and apparently being required to engineer a standalone build for the patch. This is actually my first significant contribution, so I'm feeling a little lost at this point. Is it kosher to move patches out of zk contrib and into independent repos? And what would make it easer to collaborate on in github vs. the main zk project? Many thanks for your interest and time... Aaron Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865527#action_12865527 ] Chris K Wensel commented on ZOOKEEPER-679: -- Its more of a mater of what's more utilitarian. Your code can be locked up into the apache repo where only mods must be submitted as patch files, or in github where people can branch/fork/merge at will. note that some projects are doing away with contrib folders since most of the contributions either become abandoned (partly because patch process is too onerous) or are very immature and buggy. the code is now in github, you can choose to fork it and modify it. or ignore it. Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865540#action_12865540 ] Aaron Crow commented on ZOOKEEPER-679: -- Hi Mahadev, apologies for the delayed response. Yes you're right, I didn't include a build.xml file. I'm really sorry, just haven't found the time to put all that together. Related, it's interesting to me what Chris is saying about abandoned (partly because patch process is too onerous). When I had the patch in the main project, it was pretty easy to get it running with the main project's test framework. As a standalone contrib, however, I felt kinda stymied because there's real overhead in putting everything together. Any thoughts from your end on the github approach vs. main project? Thanks for all your time and help with the patch... Aaron Offers a node design for interacting with the Java Zookeeper client. Key: ZOOKEEPER-679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679 Project: Zookeeper Issue Type: New Feature Components: contrib, java client, tests Reporter: Aaron Crow Assignee: Aaron Crow Fix For: 3.4.0 Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, ZOOKEEPER-679.patch Following up on my conversations with Patrick and Mahadev (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695). This patch includes the implementation as well as unit tests. The first unit test gives a simple high level demo of using the node API. The current implementation is simple and is only what I need withe current project I am working on. However, I am very open to any and all suggestions for improvement. This is a proposal to support a simplified node (or File) like API into a Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to Java's File API design. Although, I'm trying to make it easier in a few spots. For example, deleting a Node recursively is done by default. I also lean toward resolving Exceptions under the hood when it seems appropriate. For example, if you ask a Node if it exists, and its parent doesn't even exist, you just get a false back (rather than a nasty Exception). As for watches and ephemeral nodes, my current work does not need these things so I currently have no handling of them. But if potential users of the Node a.k.a. File design want these things, I'd be open to supporting them as reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
