[
https://issues.apache.org/jira/browse/CASSANDRA-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-828.
--------------------------------------
Resolution: Fixed
the != null check is definitely redundant. removed in r916006.
> possible NPE in StorageService
> ------------------------------
>
> Key: CASSANDRA-828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-828
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: gabriele renzi
> Assignee: gabriele renzi
> Priority: Minor
> Fix For: 0.6
>
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> the code
> {{{
> if (endPointThatLeft.equals(FBUtilities.getLocalAddress()))
> {
> logger_.info("Received removeToken gossip about myself. Is
> this node a replacement for a removed one?");
> return;
> }
> if (logger_.isDebugEnabled())
> logger_.debug("Token " + token + " removed manually (endpoint
> was " + ((endPointThatLeft == null) ? "unknown" : endPointThatLeft) + ")");
> if (endPointThatLeft != null)
> {
> removeEndPointLocally(endPointThatLeft);
> }
> }}}
> appears wrong: if it is possible for the leaving endpoint to be unknown then
> the first "if" has a possible null dereference, which can be eliminated by
> swapping the arguments or reordering the code.
> As a side note, I believe FBUtilities.getLocalAddress should probably be
> synchronized (or localInetAddress made volatile) per the usual "the java MM
> does not guarantee any change will ever be visible" mantra which may or may
> not be considered relevant :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
