[
https://issues.apache.org/jira/browse/ZOOKEEPER-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050543#comment-13050543
]
Henry Robinson commented on ZOOKEEPER-1094:
-------------------------------------------
Thanks guys. Regarding the staleness transformation - it did seem a bit weird
to me as well. If you think this patch preserves the original behaviour, maybe
we should get that committed and open another JIRA to figure out if that
behaviour is actually wrong... there are a couple of things in LE that could do
with being cleaned up, such as the fact that it doesn't use the current quorum
verifier to pass votes.
> 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
