[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-tabpanel&focusedCommentId=12853100#action_12853100 ] Sergey Doroshenko commented on ZOOKEEPER-702: - Submitted GSoC application for this. Looking forward to feedback. Btw, link to HDY04 is broken, found this work only with google. > 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 > > 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.
[jira] Created: (ZOOKEEPER-769) Leader can treat observers as quorum members
Leader can treat observers as quorum members Key: ZOOKEEPER-769 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Environment: Ubuntu Karmic x64 Reporter: Sergey Doroshenko Fix For: 3.3.0 In short: it seems leader can treat observers as quorum members. Steps to repro: 1. Server configuration: 3 voters, 2 observers (attached). 2. Bring up 2 voters and one observer. It's enough for quorum. 3. Shut down the one from the quorum who is the follower. As I understand, expected result is that leader will start a new election round so that to regain quorum. But the real situation is that it just says goodbye to that follower, and is still operable. (When I'm shutting down 3rd one -- observer -- leader starts trying to regain a quorum). (Expectedly, if on step 3 we shut down the leader, not the follower, remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Attachment: zoo1.cfg > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko > Fix For: 3.3.0 > > Attachments: zoo1.cfg > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Attachment: follower.log leader.log observer.log Logs > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko > Fix For: 3.3.0 > > Attachments: follower.log, leader.log, observer.log, zoo1.cfg > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko resolved ZOOKEEPER-769. - Resolution: Not A Problem Henry, you're right. I overlooked to add "peerType". Anyway, wouldn't it be better if server warned about such inconsistency in a config? It can infer from servers list that it should be an observer, so it could either WARN in logs that "peerType=observer" is missing, or just make itself an observer. > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko > Fix For: 3.3.0 > > Attachments: follower.log, leader.log, observer.log, zoo1.cfg > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Attachment: warning.patch Simple patch as per my suggestion above. (In git format. LMK if it's not acceptable.) > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko > Fix For: 3.3.0 > > Attachments: follower.log, leader.log, observer.log, warning.patch, > zoo1.cfg > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Attachment: ZOOKEEPER-769.patch New patch, formatted with --no-prefix. In case of inconsistency peerType is set to one from the servers list. Added test. > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: follower.log, leader.log, observer.log, warning.patch, > zoo1.cfg, ZOOKEEPER-769.patch > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-769: Status: Patch Available (was: Reopened) > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: follower.log, leader.log, observer.log, warning.patch, > zoo1.cfg, ZOOKEEPER-769.patch > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- 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-tabpanel&focusedCommentId=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] Created: (ZOOKEEPER-774) Recipes tests are slightly outdated: they do not compile against JUnit 4.8
Recipes tests are slightly outdated: they do not compile against JUnit 4.8 -- Key: ZOOKEEPER-774 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-774 Project: Zookeeper Issue Type: Bug Components: recipes Affects Versions: 3.3.0 Reporter: Sergey Doroshenko Priority: Minor Fix For: 3.4.0 As title -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-774) Recipes tests are slightly outdated: they do not compile against JUnit 4.8
[ https://issues.apache.org/jira/browse/ZOOKEEPER-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-774: Attachment: ZOOKEEPER-774.patch Pretty simple patch. Annotations added; assertXXX are changed to Assert.assertXXX. > Recipes tests are slightly outdated: they do not compile against JUnit 4.8 > -- > > Key: ZOOKEEPER-774 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-774 > Project: Zookeeper > Issue Type: Bug > Components: recipes >Affects Versions: 3.3.0 >Reporter: Sergey Doroshenko >Priority: Minor > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-774.patch > > > As title -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-774) Recipes tests are slightly outdated: they do not compile against JUnit 4.8
[ https://issues.apache.org/jira/browse/ZOOKEEPER-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-774: Status: Patch Available (was: Open) Notifying Hundson. Though not sure whether it checks recipes' code > Recipes tests are slightly outdated: they do not compile against JUnit 4.8 > -- > > Key: ZOOKEEPER-774 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-774 > Project: Zookeeper > Issue Type: Bug > Components: recipes >Affects Versions: 3.3.0 >Reporter: Sergey Doroshenko >Priority: Minor > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-774.patch > > > As title -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868777#action_12868777 ] Sergey Doroshenko commented on ZOOKEEPER-769: - So, since tests pass, should this be committed? Or should something be updated? > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: follower.log, leader.log, observer.log, warning.patch, > zoo1.cfg, ZOOKEEPER-769.patch > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-769) Leader can treat observers as quorum members
[ https://issues.apache.org/jira/browse/ZOOKEEPER-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869118#action_12869118 ] Sergey Doroshenko commented on ZOOKEEPER-769: - Yes, changes look good. > Leader can treat observers as quorum members > > > Key: ZOOKEEPER-769 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-769 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Ubuntu Karmic x64 >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: follower.log, leader.log, observer.log, warning.patch, > zoo1.cfg, ZOOKEEPER-769.patch, ZOOKEEPER-769.patch > > > In short: it seems leader can treat observers as quorum members. > Steps to repro: > 1. Server configuration: 3 voters, 2 observers (attached). > 2. Bring up 2 voters and one observer. It's enough for quorum. > 3. Shut down the one from the quorum who is the follower. > As I understand, expected result is that leader will start a new election > round so that to regain quorum. > But the real situation is that it just says goodbye to that follower, and is > still operable. (When I'm shutting down 3rd one -- observer -- leader starts > trying to regain a quorum). > (Expectedly, if on step 3 we shut down the leader, not the follower, > remaining follower starta new leader election, as it should be). -- 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-tabpanel&focusedCommentId=12873003#action_12873003
]
Sergey Doroshenko commented on ZOOKEEPER-704:
-
I have updated wiki page to describe new (quite simple and elegant) approach of
implementing server-side part of the read-only mode.
Already discussed this with Henry yesterday.
Take a look if you're interested in the details, and lmk if you have some
thoughts about this.
> 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] Created: (ZOOKEEPER-784) server-side functionality for read-only mode
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 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch Patch includes ReadOnlyZooKeeperServer and ReadOnlyReqestProcessor. This patch outlines the general idea: read-only server is spawned when peer becomes partitioned, and is able to serve read-only requests but drops state-changing ones. It's by no means a final version, however it's already possible to connect to a partitioned peer (or remain connected to it when it loses a quorum) and make read requests (write requests are dropped with explanation message). Next things to work on are: * session handling during partition. For now ReadOnlyServer creates SessionTrackerImpl and it's ok for manual tests, but that's just to make this proof-of-concept patch work * distinguish read-only clients and usual ones (depends on yet non-existent ticket about creation of read-only client), accept only read-onlies * create test cases, make all current ones pass > 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 > > > 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch Fixed JMX behaviour, now read-only server is visible in a JMX console when server is partitioned > 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 > > > 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch Added read-only functionality to client side: to create RO client, one have to pass additional boolean param to ZooKeeper's ctor; ctors with old signatures create usual clients. Now, if server is partitioned, it doesn't allow usual clients to connect. Decided not to create separate ticket for client-side change since it's anyway related to this one. > 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.
[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-tabpanel&focusedCommentId=12881313#action_12881313 ] Sergey Doroshenko commented on ZOOKEEPER-784: - --- Question about session handling --- For now (latest patch) when r/o client connects to a partitioned server, new "fake" session is created for it -- fake because it exists only in this server. When server regains the quorum, during this session's revalidation it will be rejected as invalid since leader didn't see this it. >From users' point of view it'd be good to transparently upgrade such session >to a usual session. The idea is that if leader sees that given session is >invalid but also belongs to read-only client then it re-assigns new id to id >and sends this new id to the client. The idea is good but seems error-prone. For example, what to do with r/o clients that were partitioned (and connected to partitioned server) for longer than sess timeout? At leader their sessions have already been expired, so they should be rejected. Re-assigning new session to such clients doesn't look right. But the problem here is that when servers see an invalid session they can't tell if they never saw it or if they saw it but it was expired. So, if quorum rejects r/o session (which implies this session either was never seen by quorum or is expired), there are two options from users' point of view: * ZooKeeper object becomes invalid, and application should create a new one. Reliable and consistent with current ZK * server transparently re-assigns session id for such client. Seems to have many potential problems, as described above What do you think? > 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.
[jira] Updated: (ZOOKEEPER-791) Watches get triggered during client's reconnection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-791: Attachment: incorrectly_triggered_watches.log Attached is client's log. Weird things are on lines 43-57 > Watches get triggered during client's reconnection > -- > > Key: ZOOKEEPER-791 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-791 > Project: Zookeeper > Issue Type: Bug >Reporter: Sergey Doroshenko >Priority: Minor > Attachments: incorrectly_triggered_watches.log > > > I start 2 of 3 servers of an ensemble, connect to it with zkCli.sh, do "ls / > 1" which registers a watch. > Then I kill one of 2 servers which makes alive one to lose a quorum and > forces client to reconnect. > And when the client connects to this alive server (but gets quickly dropped > by the server afterwards), watch is triggered: > WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/ > I can reproduce it only with command-line client, and quite rarely. I tried > to write unit test, but id didn't catch this. > Has anybody seen this before? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-791) Watches get triggered during client's reconnection
Watches get triggered during client's reconnection -- Key: ZOOKEEPER-791 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-791 Project: Zookeeper Issue Type: Bug Reporter: Sergey Doroshenko Priority: Minor Attachments: incorrectly_triggered_watches.log I start 2 of 3 servers of an ensemble, connect to it with zkCli.sh, do "ls / 1" which registers a watch. Then I kill one of 2 servers which makes alive one to lose a quorum and forces client to reconnect. And when the client connects to this alive server (but gets quickly dropped by the server afterwards), watch is triggered: WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/ I can reproduce it only with command-line client, and quite rarely. I tried to write unit test, but id didn't catch this. Has anybody seen this before? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch * As per Henry's suggestion, updated QuorumePeer to wait some time before starting RO server (currently it's 1 tickTime) * About watches: no, setting watches doesn't turn operation to a write operation. If a client is connected to a partitioned server and sets a watch in r/o mode, and meanwhile data is changed in the majority part, the watch will be triggered when the client reconnects to the majority. This is consistent with the current behavior, that is, if a watch is set before partitioning, it's triggered upon rejoining if there's any change * Added a test to ensure read operations succeed in r/o mode and write operations fail. Created QuorumUtil class which encapsulates quorum testing logic, e.g. allows to start/shutdown all peers or particular ones. It's used in the new test for r/o mode. I will refactor QuorumBase to be a special case of QuorumUtil. What I'll do next is update wiki page to address Patrick's comments and make r/o client to seek for r/w server (currently if client's connected to a r/o server it doesn't try to find another server). > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch In this patch: * client seeks for r/w server if it's connected to r/o server, backoffing exponentially. * "fake" session (the one assigned by r/o server) is transitioned to valid session upon connection to r/w server, transparently for the user * client receives notifications about r/o mode via default watcher * more tests > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: (was: ZOOKEEPER-784.patch) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: (was: ZOOKEEPER-784.patch) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: In Progress (was: Patch Available) > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: In Progress) > 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, 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.
[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-tabpanel&focusedCommentId=12885349#action_12885349 ] Sergey Doroshenko commented on ZOOKEEPER-784: - I've updated the wiki page (http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) to address backwards compatibility, searching of r/w server during r-o mode, session handling and other questions, and made it more structured overall. Soon I will also add some use case / recipe updated with regard to read-only mode. Overall, the latest patch presents ready-to-use implementation of the read-only mode feature. It's fully backwards compatible, new server is safe to use along with old ones, new client is safe to use against old servers etc. Documentation and tests will be improved of course, but again, this patch is ready to use. You could try this if you're interested. Consult the wiki page about usage and design details. > 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, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch Fixed issue with compatibility with C client. Now all tests should pass > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[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-tabpanel&focusedCommentId=12886686#action_12886686 ] Sergey Doroshenko commented on ZOOKEEPER-784: - Hudson says there's one failing test: QuorumZxidSyncTest.testBehindLeader. But that's strange. 1) I can't reproduce this on my machine -- all tests pass. 2) Also, this test was passing ok with previous patch. And current patch is nearly the same as the previous one, changes made after previous patch can't cause this test to fail. > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-795) eventThread isn't shutdown after a connection "session expired" event coming
[ https://issues.apache.org/jira/browse/ZOOKEEPER-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-795: Attachment: ZOOKEEPER-795.patch This simple patch fixes both issues. No tests included, verified with Daniel's class. Not sure if we need yet another 20-seconds test for this. > eventThread isn't shutdown after a connection "session expired" event coming > > > Key: ZOOKEEPER-795 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-795 > Project: Zookeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.3.1 > Environment: ubuntu 10.04 >Reporter: mathieu barcikowski >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ExpiredSessionThreadLeak.java, ZOOKEEPER-795.patch > > > Hi, > I notice a problem with the eventThread located in ClientCnxn.java file. > The eventThread isn't shutdown after a connection "session expired" event > coming (i.e. never receive EventOfDeath). > When a session timeout occurs and the session is marked as expired, the > connexion is fully closed (socket, SendThread...) expect for the eventThread. > As a result, if i create a new zookeeper object and connect through it, I got > a zombi thread which will never be kill (as for the previous zookeeper > object, the state is already close, calling close again don't do anything). > So everytime I will create a new zookeeper connection after a expired > session, I will have a one more zombi EventThread. > How to reproduce : > - Start a zookeeper client connection in debug mode > - Pause the jvm enough time to the expired event occur > - Watch for example with jvisualvm the list of threads, the sendThread is > succesfully killed, but the EventThread go to wait state for a infinity of > time > - if you reopen a new zookeeper connection, and do again the previous steps, > another EventThread will be present in infinite wait state -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko reassigned ZOOKEEPER-827: --- Assignee: Sergey Doroshenko > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-827) enable r/o mode in C client library
enable r/o mode in C client library --- Key: ZOOKEEPER-827 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 Project: Zookeeper Issue Type: Sub-task Reporter: Sergey Doroshenko Implement read-only mode functionality (in accordance with http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-827: Attachment: ZOOKEEPER-827.patch Workable version of r/o functionality. To get r/o-enabled zhandle use zookeeper_init_ro function; zookeeper_init simply delegates to it. Client seeks for r/w server if in r/o state. Default watcher receives appropriate notifications. Things to add is handling of "fake" sessions (check ZOOKEEPER-784 and wiki page for details), and tests. For now I do have tests but they are tied to my environment; I also tested added functionality with cli_mt command-line client > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-827: Status: Patch Available (was: Open) > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-827: Attachment: ZOOKEEPER-827.patch sessions handling added > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch, ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-795) eventThread isn't shutdown after a connection "session expired" event coming
[ https://issues.apache.org/jira/browse/ZOOKEEPER-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891304#action_12891304 ] Sergey Doroshenko commented on ZOOKEEPER-795: - Has anybody had a chance to look at the patch? > eventThread isn't shutdown after a connection "session expired" event coming > > > Key: ZOOKEEPER-795 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-795 > Project: Zookeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.3.1 > Environment: ubuntu 10.04 >Reporter: mathieu barcikowski >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ExpiredSessionThreadLeak.java, ZOOKEEPER-795.patch > > > Hi, > I notice a problem with the eventThread located in ClientCnxn.java file. > The eventThread isn't shutdown after a connection "session expired" event > coming (i.e. never receive EventOfDeath). > When a session timeout occurs and the session is marked as expired, the > connexion is fully closed (socket, SendThread...) expect for the eventThread. > As a result, if i create a new zookeeper object and connect through it, I got > a zombi thread which will never be kill (as for the previous zookeeper > object, the state is already close, calling close again don't do anything). > So everytime I will create a new zookeeper connection after a expired > session, I will have a one more zombi EventThread. > How to reproduce : > - Start a zookeeper client connection in debug mode > - Pause the jvm enough time to the expired event occur > - Watch for example with jvisualvm the list of threads, the sendThread is > succesfully killed, but the EventThread go to wait state for a infinity of > time > - if you reopen a new zookeeper connection, and do again the previous steps, > another EventThread will be present in infinite wait state -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-790: Attachment: ZOOKEEPER-790-follower-request-NPE.log It seems this patch introduces a bug: followers get synchronized with leader and start serving clients before leader startups its own zk instance. As the result, when a follower forward request to the leader, for example session revalidation request, it fails because leader's sessionTracker is null. Previously this was not the case because leader started its zk immediately after quorum peer is switched to LEADING state. See attached log. > Last processed zxid set prematurely while establishing leadership > - > > Key: ZOOKEEPER-790 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790 > Project: Zookeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.3.1 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, > ZOOKEEPER-790-follower-request-NPE.log, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.travis.log.bz2 > > > The leader code is setting the last processed zxid to the first of the new > epoch even before connecting to a quorum of followers. Because the leader > code sets this value before connecting to a quorum of followers > (Leader.java:281) and the follower code throws an IOException > (Follower.java:73) if the leader epoch is smaller, we have that when the > false leader drops leadership and becomes a follower, it finds a smaller > epoch and kills itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892442#action_12892442 ] Sergey Doroshenko commented on ZOOKEEPER-790: - Easy way to reproduce: * start 2 out of 3 peers * connect to the ensemble by zkCli.sh * shutdown a peer, wait a bit * start the peer Due to NPE (which is not seen in logs however) servers can't form a quorum, and client is unable to reconnect. > Last processed zxid set prematurely while establishing leadership > - > > Key: ZOOKEEPER-790 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790 > Project: Zookeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.3.1 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, > ZOOKEEPER-790-follower-request-NPE.log, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.travis.log.bz2 > > > The leader code is setting the last processed zxid to the first of the new > epoch even before connecting to a quorum of followers. Because the leader > code sets this value before connecting to a quorum of followers > (Leader.java:281) and the follower code throws an IOException > (Follower.java:73) if the leader epoch is smaller, we have that when the > false leader drops leadership and becomes a follower, it finds a smaller > epoch and kills itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-827: Attachment: ZOOKEEPER-827.patch * test added * made client backwards compatible with old server Overall, that's it. Fully workable r/o mode. Of course, to test it you also need to apply ZOOKEEPER-784 > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch, ZOOKEEPER-827.patch, > ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-827: Status: Open (was: Patch Available) cancelling patch since test won't pass till server-side changes is integrated to the trunk > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch, ZOOKEEPER-827.patch, > ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892536#action_12892536 ] Sergey Doroshenko commented on ZOOKEEPER-790: - Hey Flavio, Patch works ok: passes both manual testing and my unit test which was previously failing. It looks conceptually correct, I'd give it +1 if I'd have such authority :) > Last processed zxid set prematurely while establishing leadership > - > > Key: ZOOKEEPER-790 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790 > Project: Zookeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.3.1 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, > ZOOKEEPER-790-follower-request-NPE.log, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.travis.log.bz2, ZOOKEEPER-790.v2.patch > > > The leader code is setting the last processed zxid to the first of the new > epoch even before connecting to a quorum of followers. Because the leader > code sets this value before connecting to a quorum of followers > (Leader.java:281) and the follower code throws an IOException > (Follower.java:73) if the leader epoch is smaller, we have that when the > false leader drops leadership and becomes a follower, it finds a smaller > epoch and kills itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-790: Attachment: ZOOKEEPER-790-test.patch The test that was failing was the test for r/o mode, so it wouldn't apply here. I've extracted necessary code from it and made it a test case in QuorumTest. It fails against current trunk but passes against latest patch. This test case uses QuorumUtil which I also extracted from my r/o mode patch. I made it for convenient quorum testing, it's more handy than current QuorumBase, and I plan to make QuorumBase a special case of it. > Last processed zxid set prematurely while establishing leadership > - > > Key: ZOOKEEPER-790 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790 > Project: Zookeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.3.1 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, > ZOOKEEPER-790-follower-request-NPE.log, ZOOKEEPER-790-test.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.travis.log.bz2, > ZOOKEEPER-790.v2.patch > > > The leader code is setting the last processed zxid to the first of the new > epoch even before connecting to a quorum of followers. Because the leader > code sets this value before connecting to a quorum of followers > (Leader.java:281) and the follower code throws an IOException > (Follower.java:73) if the leader epoch is smaller, we have that when the > false leader drops leadership and becomes a follower, it finds a smaller > epoch and kills itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892721#action_12892721 ] Sergey Doroshenko commented on ZOOKEEPER-790: - btw, Flavio, there are a few lines with trailing whitespaces in your patch, fix them > Last processed zxid set prematurely while establishing leadership > - > > Key: ZOOKEEPER-790 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790 > Project: Zookeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.3.1 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.3.2, 3.4.0 > > Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, > ZOOKEEPER-790-follower-request-NPE.log, ZOOKEEPER-790-test.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, > ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.travis.log.bz2, > ZOOKEEPER-790.v2.patch > > > The leader code is setting the last processed zxid to the first of the new > epoch even before connecting to a quorum of followers. Because the leader > code sets this value before connecting to a quorum of followers > (Leader.java:281) and the follower code throws an IOException > (Follower.java:73) if the leader epoch is smaller, we have that when the > false leader drops leadership and becomes a follower, it finds a smaller > epoch and kills itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: In Progress (was: Patch Available) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch updated the patch wrt latest trunk's state > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: In Progress) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 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.
[jira] Created: (ZOOKEEPER-830) forrest docs for read-only mode
forrest docs for read-only mode --- Key: ZOOKEEPER-830 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-830 Project: Zookeeper Issue Type: Sub-task Reporter: Sergey Doroshenko Assignee: Sergey Doroshenko -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-830) forrest docs for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-830: Attachment: ZOOKEEPER-830.patch Forrest docs for read-only mode. * Described usage of r-o mode: API, session handling considerations * Described use cases: configuration management and leader election * Linked to the r-o page from index page, programmers guide etc Also, fixed a typo in leader election recipe. In _"... where j is the smallest sequence number such that j < i and n_j is a znode in C"_ : the word "smallest" should be changed to "highest". "smallest" works too, but with herd effect. Tested with forrest that everything is generated correctly. > forrest docs for read-only mode > --- > > Key: ZOOKEEPER-830 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-830 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-830.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 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.
[jira] Work started: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ZOOKEEPER-784 started by Sergey Doroshenko. > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch improved documentation > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: In Progress) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > 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.
[jira] Updated: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-827: Attachment: ZOOKEEPER-827.patch improved documentation > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch, ZOOKEEPER-827.patch, > ZOOKEEPER-827.patch, ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-830) forrest docs for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-830: Attachment: ZOOKEEPER-830.patch added usage in command-line clients > forrest docs for read-only mode > --- > > Key: ZOOKEEPER-830 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-830 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-830.patch, ZOOKEEPER-830.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-733) use netty to handle client connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896504#action_12896504 ] Sergey Doroshenko commented on ZOOKEEPER-733: - I would like to update my read-only mode patch to apply correctly on top of this one. The problem is, I can't apply this patch to trunk. Could you re-generate it against current trunk? > use netty to handle client connections > -- > > Key: ZOOKEEPER-733 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-733 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Benjamin Reed >Assignee: Patrick Hunt > Fix For: 3.4.0 > > Attachments: accessive.jar, flowctl.zip, moved.zip, > QuorumTestFailed_sessionmoved_TRACE_LOG.txt.gz, ZOOKEEPER-733.patch, > ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, > ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, > ZOOKEEPER-733.patch > > > we currently have our own asynchronous NIO socket engine to be able to handle > lots of clients with a single thread. over time the engine has become more > complicated. we would also like the engine to use multiple threads on > machines with lots of cores. plus, we would like to be able to support things > like SSL. if we switch to netty, we can simplify our code and get the > previously mentioned benefits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-733) use netty to handle client connections
[
https://issues.apache.org/jira/browse/ZOOKEEPER-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896996#action_12896996
]
Sergey Doroshenko commented on ZOOKEEPER-733:
-
I noticed that NettyServerCnxn class contains big copy-paste of all 4-letter
commands and checkFourLetterWord method is also almost identical to one in
NIOServerCnxn. The only difference is:
1) commands in NettyCnxn don't extendThread
2) checkFourLetterWord methods differ in I/O a bit. But big "if (len==someCmd)
{ start someCmd }" part is the same.
So, questions:
1) is there any practical reason for commands in NIOCnxn being Threads? If no,
they are identical with ones from NettyCnxn, so we could move all commands to
ServerCnxn superclass
2) big part of checkFourLetterWord (IO-unrelated one, described above) could
also be moved to superclass
> use netty to handle client connections
> --
>
> Key: ZOOKEEPER-733
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-733
> Project: Zookeeper
> Issue Type: Improvement
> Components: server
>Reporter: Benjamin Reed
>Assignee: Patrick Hunt
> Fix For: 3.4.0
>
> Attachments: accessive.jar, flowctl.zip, moved.zip,
> QuorumTestFailed_sessionmoved_TRACE_LOG.txt.gz, ZOOKEEPER-733.patch,
> ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch,
> ZOOKEEPER-733.patch, ZOOKEEPER-733.patch, ZOOKEEPER-733.patch,
> ZOOKEEPER-733.patch, ZOOKEEPER-733.patch
>
>
> we currently have our own asynchronous NIO socket engine to be able to handle
> lots of clients with a single thread. over time the engine has become more
> complicated. we would also like the engine to use multiple threads on
> machines with lots of cores. plus, we would like to be able to support things
> like SSL. if we switch to netty, we can simplify our code and get the
> previously mentioned benefits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[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-tabpanel&focusedCommentId=12898832#action_12898832 ] Sergey Doroshenko commented on ZOOKEEPER-784: - Thanks Henry! Eagerly looking forward to another +1 and getting r-o mode into the trunk I also have a patch that applies above ZOOKEEPER-733 changes, so if those go to the trunk first, I'll upload the patch > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch The patch against latest trunk state > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Open (was: Patch Available) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Status: Patch Available (was: Open) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, 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.
[jira] Updated: (ZOOKEEPER-784) server-side functionality for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Doroshenko updated ZOOKEEPER-784: Attachment: ZOOKEEPER-784.patch Hey Flavio, thanks for reviewing! Re your comments: 1. added warn messages both to server- and client-side 2. done 3. done 4. r-o server gets killed in "finally" block of LOOKING case of QuorumPeer#run (QuorumPeer#645 in the latest patch). Interesting thing is, it may actually won't have started by the time shutdown is called (if peer regains the quorum during the grace period), but #shutdown is called in any case > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 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.
[jira] Commented: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907053#action_12907053 ] Sergey Doroshenko commented on ZOOKEEPER-827: - This is fully workable solution that depends on ZOOKEEPER-784 only > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch, ZOOKEEPER-827.patch, > ZOOKEEPER-827.patch, ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-827) enable r/o mode in C client library
[ https://issues.apache.org/jira/browse/ZOOKEEPER-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907542#action_12907542 ] Sergey Doroshenko commented on ZOOKEEPER-827: - Since ZOOKEEPER-784 is not in trunk, Hudson will reject this patch. But if you apply 784's patch, this one becomes "patch available" > enable r/o mode in C client library > --- > > Key: ZOOKEEPER-827 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-827 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-827.patch, ZOOKEEPER-827.patch, > ZOOKEEPER-827.patch, ZOOKEEPER-827.patch > > > Implement read-only mode functionality (in accordance with > http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode) in C client library -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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-tabpanel&focusedCommentId=12930686#action_12930686 ] Sergey Doroshenko commented on ZOOKEEPER-784: - Hi Patrick, Currently I'm in the final stage of my Facebook's internship, and I want to keep good pace and not be distracted by other things. Hopefully r-o mode is not release-blocking feature, so I hope it'll be ok if I resubmit the patch in 3 weeks. But if this should be done sooner, let me know and I'll try to find a time :) > 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 > Components: server >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Fix For: 3.4.0 > > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, 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.
