[jira] [Assigned] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaoshu reassigned ZOOKEEPER-2572:
-
Assignee: gaoshu
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
>Assignee: gaoshu
> Fix For: 3.5.4, 3.6.0, 3.4.11
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150402#comment-16150402
]
gaoshu commented on ZOOKEEPER-2572:
---
In addition, I think the {{itr.logFile.delete() }} can be replaced by
{{Files.delete(itr.logFile.toPath());}}. If failed, Files.delete can throw an
exception, which this is useful for error reporting and to diagnosed why a file
cannot be deleted. Then the function will return void if successful, or throw
an exception. Then we can log the detailed error and rethrow it.
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.5.4, 3.6.0, 3.4.11
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150402#comment-16150402
]
gaoshu edited comment on ZOOKEEPER-2572 at 9/1/17 11:54 AM:
In addition, I think the {{itr.logFile.delete()}} can be replaced by
{{Files.delete(itr.logFile.toPath())}}. If failed, Files.delete can throw an
exception, which this is useful for error reporting and to diagnosed why a file
cannot be deleted. Then the function will return void if successful, or throw
an exception. Then we can log the detailed error and rethrow it. But the
Files.delete is available for jdk1.7 +
was (Author: gaoshu):
In addition, I think the {{itr.logFile.delete()}} can be replaced by
{{Files.delete(itr.logFile.toPath())}}. If failed, Files.delete can throw an
exception, which this is useful for error reporting and to diagnosed why a file
cannot be deleted. Then the function will return void if successful, or throw
an exception. Then we can log the detailed error and rethrow it.
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.5.4, 3.6.0, 3.4.11
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16150402#comment-16150402
]
gaoshu edited comment on ZOOKEEPER-2572 at 9/1/17 11:52 AM:
In addition, I think the {{itr.logFile.delete()}} can be replaced by
{{Files.delete(itr.logFile.toPath())}}. If failed, Files.delete can throw an
exception, which this is useful for error reporting and to diagnosed why a file
cannot be deleted. Then the function will return void if successful, or throw
an exception. Then we can log the detailed error and rethrow it.
was (Author: gaoshu):
In addition, I think the {{itr.logFile.delete() }} can be replaced by
{{Files.delete(itr.logFile.toPath());}}. If failed, Files.delete can throw an
exception, which this is useful for error reporting and to diagnosed why a file
cannot be deleted. Then the function will return void if successful, or throw
an exception. Then we can log the detailed error and rethrow it.
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.5.4, 3.6.0, 3.4.11
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaoshu updated ZOOKEEPER-2572:
--
Comment: was deleted
(was: IMO, the exception happened in FileTxnLog.truncate can be got caught in
that function. log exception, release resource and return false. Then the
dead code will be work. )
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.5.4, 3.6.0, 3.4.11
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16148386#comment-16148386
]
gaoshu commented on ZOOKEEPER-2572:
---
IMO, the exception happened in FileTxnLog.truncate can be got caught in that
function. log exception, release resource and return false. Then the dead
code will be work.
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.5.4, 3.6.0, 3.4.11
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ZOOKEEPER-2488) Unsynchronized access to shuttingDownLE in QuorumPeer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141473#comment-16141473 ] gaoshu edited comment on ZOOKEEPER-2488 at 8/30/17 10:32 AM: - Hi, [~hanm] I don't understand why need to protect the entire state of QuorumPeer. I looked through the code. In my view, the QuorumPeer contains two important state, QV and FLE. The FLE will be restarted when the QV changed whatever the server state is, namely reconfig op. If the QuorumPeer is LEADER or FOLLOWER, QuorumPeer state will be updated in function QuorumPeer::processReconfig. But if QuorumPeer is LOOKING, shuttingDownLE may be changed to true and QV updated, and then a new FLE object is created in main loop of QuorumPeer. So I think the shuttingDownLE is only used by FLE to inform QuorumPeer to create a new FLE object under the condition of self.getServerState() == LOOKING. And it is sufficient to add volatile alone. Please point our my errors, thank you very much. was (Author: gaoshu): Hi, [~hanm] I don't understand why need to protect the entire state of QuorumPeer. I looked through the code. The QuorumPeer contains two important state the QV and FLE. The FLE will be restarted when the QV changed whatever the server state is, namely reconfig op. If the QuorumPeer is LEADER or FOLLOWER, QuorumPeer state will be updated in function QuorumPeer::processReconfig. But if QuorumPeer is LOOKING, shuttingDownLE may be changed to true and QV updated, and then a new FLE object is created in main loop of QuorumPeer. So I think the shuttingDownLE is only used by FLE to inform QuorumPeer to create a new FLE object under the condition of self.getServerState() == LOOKING. And it is sufficient to add volatile alone. Please point our my errors, thank you very much. > 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)
[jira] [Assigned] (ZOOKEEPER-915) Errors that happen during sync() processing at the leader do not get propagated back to the client.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaoshu reassigned ZOOKEEPER-915: Assignee: gaoshu > Errors that happen during sync() processing at the leader do not get > propagated back to the client. > --- > > Key: ZOOKEEPER-915 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-915 > Project: ZooKeeper > Issue Type: Bug >Reporter: Benjamin Reed >Assignee: gaoshu > Fix For: 3.5.4, 3.6.0 > > > If an error in sync() processing happens at the leader (SESSION_MOVED for > example), they are not propagated back to the client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (ZOOKEEPER-2488) Unsynchronized access to shuttingDownLE in QuorumPeer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141473#comment-16141473 ] gaoshu edited comment on ZOOKEEPER-2488 at 8/28/17 9:18 AM: Hi, [~hanm] I don't understand why need to protect the entire state of QuorumPeer. I looked through the code. The QuorumPeer contains two important state the QV and FLE. The FLE will be restarted when the QV changed whatever the server state is, namely reconfig op. If the QuorumPeer is LEADER or FOLLOWER, QuorumPeer state will be updated in function QuorumPeer::processReconfig. But if QuorumPeer is LOOKING, shuttingDownLE may be changed to true and QV updated, and then a new FLE object is created in main loop of QuorumPeer. So I think the shuttingDownLE is only used by FLE to inform QuorumPeer to create a new FLE object under the condition of self.getServerState() == LOOKING. And it is sufficient to add volatile alone. Please point our my errors, thank you very much. was (Author: gaoshu): Hi, [~hanm] I have some questions about this jira, can you give me some advice? I looked through the code and ZOOKEEPER-2080. 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)
[jira] [Comment Edited] (ZOOKEEPER-2488) Unsynchronized access to shuttingDownLE in QuorumPeer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16141473#comment-16141473 ] gaoshu edited comment on ZOOKEEPER-2488 at 8/28/17 7:47 AM: Hi, [~hanm] I have some questions about this jira, can you give me some advice? I looked through the code and ZOOKEEPER-2080. 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] was (Author: gaoshu): 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)
[jira] [Commented] (ZOOKEEPER-2488) Unsynchronized access to shuttingDownLE in QuorumPeer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2488) Unsynchronized access to shuttingDownLE in QuorumPeer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gaoshu updated ZOOKEEPER-2488: -- Comment: was deleted (was: i think we just add 'volatile' to the variable shuttingDownLE. ) > 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)
[jira] [Commented] (ZOOKEEPER-2488) Unsynchronized access to shuttingDownLE in QuorumPeer
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137822#comment-16137822 ] gaoshu commented on ZOOKEEPER-2488: --- i think we just add 'volatile' to the variable shuttingDownLE. > 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 > 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)
