You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "Mukul Kumar Singh (JIRA)" <ji...@apache.org> on 2018/10/01 17:39:00 UTC
[jira] [Commented] (RATIS-336) LeaderState.isBootStrappingPeer may
have NPE
[ https://issues.apache.org/jira/browse/RATIS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634377#comment-16634377 ]
Mukul Kumar Singh commented on RATIS-336:
-----------------------------------------
Thanks for working on this [~szetszwo]. The patch looks really good to me.
1) I feel getHandler, should be replaced with something like execute, so getHandler().run() -> is replaced with execute,
also in place of handler being of executable type, can this be replaced with a supplier function.
2) Also wanted to understand in LeaderState#EventProcessor#run, why do we need checkStaging.
> LeaderState.isBootStrappingPeer may have NPE
> --------------------------------------------
>
> Key: RATIS-336
> URL: https://issues.apache.org/jira/browse/RATIS-336
> Project: Ratis
> Issue Type: Bug
> Components: server
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Tsz Wo Nicholas Sze
> Priority: Major
> Attachments: r336_20180928.patch
>
>
> {code}
> //LeaderState
> boolean isBootStrappingPeer(RaftPeerId peerId) {
> return inStagingState() && getStagingState().contains(peerId);
> }
> boolean inStagingState() {
> return stagingState != null;
> }
>
> ConfigurationStagingState getStagingState() {
> return stagingState;
> }
> {code}
> Since stagingState is volatile, it could be set to null between inStagingState() and contains(..).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)