[jira] Commented: (ZOOKEEPER-549) Refactor Followers and related classes into a Peer->Follower hierarchy in preparation for Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764577#action_12764577 ] Hadoop QA commented on ZOOKEEPER-549: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12421844/ZOOKEEPER-549.patch against trunk revision 823371. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. -1 findbugs. The patch appears to introduce 2 new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/21/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/21/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/21/console This message is automatically generated. > Refactor Followers and related classes into a Peer->Follower hierarchy in > preparation for Observers > --- > > Key: ZOOKEEPER-549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-549 > Project: Zookeeper > Issue Type: Improvement > Components: quorum, server >Affects Versions: 3.2.1 >Reporter: Henry Robinson >Assignee: Henry Robinson > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-549.patch > > > For the Observers patch (ZOOKEEPER-368), a lot of functionality is shared > between Followers and Observers. To avoid copying code, it makes sense to > push the common code into a parent Peer class and specialise it for Followers > and Observers. At the same time, some of the lengthier methods in Follower > can be broken up to make the code more readable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-549) Refactor Followers and related classes into a Peer->Follower hierarchy in preparation for Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-549: - Attachment: ZOOKEEPER-549.patch > Refactor Followers and related classes into a Peer->Follower hierarchy in > preparation for Observers > --- > > Key: ZOOKEEPER-549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-549 > Project: Zookeeper > Issue Type: Improvement > Components: quorum, server >Affects Versions: 3.2.1 >Reporter: Henry Robinson >Assignee: Henry Robinson > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-549.patch > > > For the Observers patch (ZOOKEEPER-368), a lot of functionality is shared > between Followers and Observers. To avoid copying code, it makes sense to > push the common code into a parent Peer class and specialise it for Followers > and Observers. At the same time, some of the lengthier methods in Follower > can be broken up to make the code more readable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-549) Refactor Followers and related classes into a Peer->Follower hierarchy in preparation for Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-549: - Status: Patch Available (was: Open) This patch refactors Followers into a Peer->Follower hierarchy in preparation for the upcoming Observers patch (ZOOKEEPER-368). There's no new functionality in this patch, save for the introduction of the getView API in QuorumPeer which is tested by two tests in QuorumTest. All tests pass when this patch is applied against trunk. For ease of review, I've listed the main changes below: 1. A Peer class has been introduced which is a superclass of Follower (and, eventually, Observer). Functionality common to all peers has been moved into this class. 2. Follower.followLeader has been refactored into a driver for three methods contained in Peer. These three methods are: connectToLeader(InetSocketAddress), registerWithLeader(int pktType) and syncWithLeader(long newLeaderzxid). Observers will contain their own driver method which calls these three methods in the superclass. 3. Similarly, FollowerZooKeeperHandler has been refactored into PeerZooKeeperHandler and FollowerZooKeeperHandler. 4. FollowerHandler has been renamed PeerHandler. The sock variable has been made protected and is accessed via getSocket(). 5. ZooKeeperServer.getTouchSnapshot has been made protected as it is not called outside its own class. 6. FollowerCnxAcceptor has been renamed PeerCnxAcceptor 7. QuorumPeer has a new getView API which returns the internally held map of QuorumPeers, plus a viewContains method to determine if a server is in that map. > Refactor Followers and related classes into a Peer->Follower hierarchy in > preparation for Observers > --- > > Key: ZOOKEEPER-549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-549 > Project: Zookeeper > Issue Type: Improvement > Components: quorum, server >Affects Versions: 3.2.1 >Reporter: Henry Robinson >Assignee: Henry Robinson > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-549.patch > > > For the Observers patch (ZOOKEEPER-368), a lot of functionality is shared > between Followers and Observers. To avoid copying code, it makes sense to > push the common code into a parent Peer class and specialise it for Followers > and Observers. At the same time, some of the lengthier methods in Follower > can be broken up to make the code more readable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-462) Last hint for open ledger
[ https://issues.apache.org/jira/browse/ZOOKEEPER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764566#action_12764566 ] Utkarsh Srivastava commented on ZOOKEEPER-462: -- The (new) client code is pretty much structured that way. Determining the last entry-id (recovery process) is separate from the process of opening the ledger. > Last hint for open ledger > - > > Key: ZOOKEEPER-462 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-462 > Project: Zookeeper > Issue Type: New Feature > Components: contrib-bookkeeper >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-462.patch > > > In some use cases of BookKeeper, it is useful to be able to read from a > ledger before closing the ledger. To enable such a feature, the writer has to > be able to communicate to a reader how many entries it has been able to write > successfully. The main idea of this jira is to continuously update a znode > with the number of successful writes, and a reader can, for example, watch > the node for changes. > I was thinking of having a configuration parameter to state how often a > writer should update the hint on ZooKeeper (e.g., every 1000 requests, every > 10,000 requests). Clearly updating more often increases the overhead of > writing to ZooKeeper, although the impact on the performance of writes to > BookKeeper should be minimal given that we make an asynchronous call to > update the hint. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-462) Last hint for open ledger
[ https://issues.apache.org/jira/browse/ZOOKEEPER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764535#action_12764535 ] Benjamin Reed commented on ZOOKEEPER-462: - if the client asks all the bookies he may not be able to get the last committed entry if we allow for failures. the safest thing to do would be to get the last entry from each bookie and then use the entry id in the last committed field. that would mean that you would never be able to see the actual last committed record. i think it would be good to allow the client to specify the last committed entry on the open. that way we allow the client to figure out the last committed record any way it wants, via communication from other processes for example, and it would keep the open code simple: it would just use the id it wouldn't need to worry about recovery. > Last hint for open ledger > - > > Key: ZOOKEEPER-462 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-462 > Project: Zookeeper > Issue Type: New Feature > Components: contrib-bookkeeper >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-462.patch > > > In some use cases of BookKeeper, it is useful to be able to read from a > ledger before closing the ledger. To enable such a feature, the writer has to > be able to communicate to a reader how many entries it has been able to write > successfully. The main idea of this jira is to continuously update a znode > with the number of successful writes, and a reader can, for example, watch > the node for changes. > I was thinking of having a configuration parameter to state how often a > writer should update the hint on ZooKeeper (e.g., every 1000 requests, every > 10,000 requests). Clearly updating more often increases the overhead of > writing to ZooKeeper, although the impact on the performance of writes to > BookKeeper should be minimal given that we make an asynchronous call to > update the hint. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-550) Java Queue Recipe
[ https://issues.apache.org/jira/browse/ZOOKEEPER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764502#action_12764502 ] Henry Robinson commented on ZOOKEEPER-550: -- Looks good! In offer(...) - would it be better to catch the NoNodeException and create the root then, rather than requiring an RPC every time? > Java Queue Recipe > - > > Key: ZOOKEEPER-550 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-550 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.2.1 >Reporter: Steven Cheng >Priority: Minor > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-550.patch > > > This patch adds a recipe for creating a distributed queue with ZooKeeper > similar to the WriteLock recipe and some sequential tests. This early > attempt follows the Java BlockingQueue interface, though it doesn't implement > it since I don't think there's a good reason for it to be Iterable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
