[
https://issues.apache.org/jira/browse/ZOOKEEPER-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050552#comment-13050552
]
Flavio Junqueira commented on ZOOKEEPER-1094:
---------------------------------------------
+1, it sounds good to me to get these improvements in and have another jira to
discuss the staleness issue. On the use of quorum verifier, we have brought up
a number of times the option of deprecating LeaderElection (at least I did
bring up), and this was one reason at the time we introduced quorum verifiers
to not have it in LeaderElection. We should also consider deprecating AuthFLE.
We don't even have tests for it, and to my knowledge, no one uses it.
> Small improvements to LeaderElection and Vote classes
> -----------------------------------------------------
>
> Key: ZOOKEEPER-1094
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1094
> Project: ZooKeeper
> Issue Type: Improvement
> Components: quorum
> Reporter: Henry Robinson
> Assignee: Henry Robinson
> Priority: Minor
> Attachments: ZK-1094.patch, ZK-1094.patch
>
>
> 1. o.a.z.q.Vote is a struct-style class, whose fields are public and not
> final.
> In general, we should prefer making the fields of these kind of classes
> final, and hiding them behind getters for the following reasons:
> * Marking them as final allows clients of the class not to worry about any
> synchronisation when accessing the fields
> * Hiding them behind getters allows us to change the implementation of the
> class without changing the API.
> Object creation is very cheap. It's ok to create new Votes rather than mutate
> existing ones.
> 2. Votes are mainly used in the LeaderElection class. In this class a map of
> addresses to votes is passed in to countVotes, which modifies the map
> contents inside an iterator (and therefore changes the object passed in by
> reference). This is pretty gross, so at the same time I've slightly
> refactored this method to return information about the number of validVotes
> in the ElectionResult class, which is returned by countVotes.
> 3. The previous implementation of countVotes was quadratic in the number of
> votes. It is possible to do this linearly. No real speed-up is expected as a
> result, but it salves the CS OCD in me :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
