[
https://issues.apache.org/jira/browse/CURATOR-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15939492#comment-15939492
]
Cameron McKenzie commented on CURATOR-395:
------------------------------------------
Do you happen to have a test case that can reproduce this?
The only way I can see that localCreateMethod could end up null would be if two
threads called createNode() at the same time and both got inside the
if(localCreateMethod == null) block together.
But, when start() gets called on the PersistentNode it synchronously calls into
createNode(), so this should always happen first.
The only possible way I can see that it could happen is if the
ConnectionStateLister got a RECONNECTED event after it was registered (in the
start method), but before the createNode() call from the start() method was
complete.
Having said all of that, I'm not sure why the createMethod is an
AtomicReference, or why it's instantiated lazily. We know everything we need to
know to just create this as a standard variable in the constructor as far as I
can tell.
> Potential null dereference in PersistentNode
> --------------------------------------------
>
> Key: CURATOR-395
> URL: https://issues.apache.org/jira/browse/CURATOR-395
> Project: Apache Curator
> Issue Type: Bug
> Reporter: Ted Yu
> Assignee: Jordan Zimmerman
> Priority: Minor
>
> {code}
> if ( localCreateMethod == null )
> {
> CreateModable<ACLBackgroundPathAndBytesable<String>>
> tempCreateMethod = useProtection ?
> client.create().creatingParentContainersIfNeeded().withProtection() :
> client.create().creatingParentContainersIfNeeded();
> if ( createMethod.compareAndSet(null, tempCreateMethod) )
> {
> localCreateMethod = tempCreateMethod;
> }
> }
> localCreateMethod.withMode(getCreateMode(existingPath !=
> null)).inBackground(backgroundCallback).forPath(createPath, data.get());
> {code}
> Before calling withMode(), localCreateMethod should be checked against null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
