Hudson build is back to normal : ZooKeeper-trunk #852
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/852/
[jira] Commented: (ZOOKEEPER-784) server-side functionality for read-only mode
[
https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881746#action_12881746
]
Henry Robinson commented on ZOOKEEPER-784:
--
I like the idea of fake sessions fine, although I think that the upgrade
process might be complex. Another possibility is to do away with sessions in
read-only mode (because they're mainly used to maintain state about watches,
which don't make sense on a read-only server).
Sergey - just looked over your patch. Nice job! Couple of questions:
1. In QuorumPeer.java, I can't quite follow the logic in this part of the patch:
{code}
while (running) {
switch (getPeerState()) {
case LOOKING:
+LOG.info(LOOKING);
+ReadOnlyZooKeeperServer roZk = null;
try {
-LOG.info(LOOKING);
+roZk = new ReadOnlyZooKeeperServer(
+logFactory, this,
+new ZooKeeperServer.BasicDataTreeBuilder(),
+this.zkDb);
+roZk.startup();
+
{code}
- is it sensible to start a ROZKServer every time a server enters the 'LOOKING'
state, or should there be some kind of delay before it decides it is
partitioned? Otherwise when a leader is lost and the quorum is doing a
re-election, r/w clients that try and connect would get (I think) 'can't be
read-only' messages .
2. What are you doing about watches? It seems to me that setting a watch turns
a read operation into a read / write operation, and the client should be told
that watch registration failed. If you can do this you don't have to worry so
much about session migration because there's very little session state
maintained by a ROZKServer on behalf of the client.
3. This patch has got to the point where it might be good if you started adding
some tests to validate any further development you do.
server-side functionality for read-only mode
Key: ZOOKEEPER-784
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-784
Project: Zookeeper
Issue Type: Sub-task
Reporter: Sergey Doroshenko
Assignee: Sergey Doroshenko
Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch,
ZOOKEEPER-784.patch
As per http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode , create
ReadOnlyZooKeeperServer which comes into play when peer is partitioned.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Quorum tests improvement
While incorporating tests for read-only mode, I found I don't like how QuorumBase, the main utility for quorum testing, is made -- it has 5 fields for 5 QuorumPeers, also 5 fields for ports, 5 fields for directories. In general, it's very inflexible (you can't easily shutdown particular peer and then bring up, etc) and hard-coded. I think it would be nice to create a class which would setup 2n+1 peers, and it would be possible to start/stop all peers / particular peer / n+1 peers etc. And make QuorumBase particular case of this class with n=2. What do you think? -- Regards, Sergey
[jira] Commented: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model
[ https://issues.apache.org/jira/browse/ZOOKEEPER-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881895#action_12881895 ] Flavio Paiva Junqueira commented on ZOOKEEPER-702: -- Three very quick comments, Abmar: 1- Please don't forget to add license headers to each one of the new files; 2- Please add javadocs; 3- I was wondering what the current plan is to configure which failure detector to use and the parameters of the failure detector. In the current patch, it looks like you're setting it directly in the code. GSoC 2010: Failure Detector Model - Key: ZOOKEEPER-702 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702 Project: Zookeeper Issue Type: Wish Reporter: Henry Robinson Assignee: Abmar Barros Attachments: bertier-pseudo.txt, chen-pseudo.txt, phiaccrual-pseudo.txt, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch Failure Detector Module Possible Mentor Henry Robinson (henry at apache dot org) Requirements Java, some distributed systems knowledge, comfort implementing distributed systems protocols Description ZooKeeper servers detects the failure of other servers and clients by counting the number of 'ticks' for which it doesn't get a heartbeat from other machines. This is the 'timeout' method of failure detection and works very well; however it is possible that it is too aggressive and not easily tuned for some more unusual ZooKeeper installations (such as in a wide-area network, or even in a mobile ad-hoc network). This project would abstract the notion of failure detection to a dedicated Java module, and implement several failure detectors to compare and contrast their appropriateness for ZooKeeper. For example, Apache Cassandra uses a phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which is much more tunable and has some very interesting properties. This is a great project if you are interested in distributed algorithms, or want to help re-factor some of ZooKeeper's internal code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
