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)