[
https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141473#comment-16141473
]
gaoshu commented on ZOOKEEPER-2488:
-----------------------------------
I have some questions about this jira, can you give me some advice?
I looked through the code and ZOOKEEPER-2080. IMHO, In FLE, the shuttingDownLE
change to true under the condition of self.geePeerStat() == LOOKING. So other
threads owned by LEADER or FOLLOWER may not be reached
QuorumPeer::restartLeaderElection, where shuttingDownLE is accessed. In fact,
the objects of LEADER or FOLLOWER may not be exist.
On the other sides, if state is not LOOKING, shuttingDownLE won't be changed
from false to true and it is only accessed when need to reconfig. So, it
looks like that shuttingDownLE is only to inform the main loop in QuorumPeer to
start a new FLE.
Very appreciate your advice. [~hanm]
> Unsynchronized access to shuttingDownLE in QuorumPeer
> -----------------------------------------------------
>
> Key: ZOOKEEPER-2488
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2488
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.5.2
> Reporter: Michael Han
> Assignee: gaoshu
> Fix For: 3.5.4, 3.6.0
>
>
> Access to shuttingDownLE in QuorumPeer is not synchronized here:
> https://github.com/apache/zookeeper/blob/3c37184e83a3e68b73544cebccf9388eea26f523/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java#L1066
> https://github.com/apache/zookeeper/blob/3c37184e83a3e68b73544cebccf9388eea26f523/src/java/main/org/
> The access should be synchronized as the same variable might be accessed
> in QuormPeer::restartLeaderElection, which is synchronized.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
