Github user afine commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/247#discussion_r117582004
--- Diff: src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java
---
@@ -682,27 +682,19 @@ public void setQuorumAddress(InetSocketAddress addr){
}
public InetSocketAddress getElectionAddress(){
- synchronized (QV_LOCK) {
- return myElectionAddr;
- }
+ return myElectionAddr;
--- End diff --
> All set code path was protected by QV_LOCK already, which implies that
whoever calls set* should already acquire the QV_LOCK.
Not sure about this one. `setElectionAddress` is called by
`recreateSocketAddresses` which is called by `QuorumCnxManager#Listener.run`
without acquiring QV_LOCK. Not sure what the implication of this is. Although I
believe you are correct about `setClientAddress`.
> if we get out dated addr (in case the current quorum peer is being
reconfigured) and sent this to another peer, another peer will not able to
connect but that's fine, it will retry until at certain point later it will get
correct information.
What is the behavior if we are able to connect to the "incorrect peer".
Will we eventually disconnect or do we stay connected until reconfiguration
occurs again?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
