curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-310) Race in PersistentNode startup
Date Tue, 29 Mar 2016 02:07:25 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215259#comment-15215259
] 

ASF GitHub Bot commented on CURATOR-310:
----------------------------------------

Github user cammckenzie commented on a diff in the pull request:

    https://github.com/apache/curator/pull/140#discussion_r57663597
  
    --- Diff: curator-recipes/src/main/java/org/apache/curator/framework/recipes/nodes/PersistentNode.java
---
    @@ -317,6 +317,7 @@ public String getActualPath()
         public void setData(byte[] data) throws Exception
         {
             data = Preconditions.checkNotNull(data, "data cannot be null");
    +        Preconditions.checkState(nodePath.get() != null, "initial create has not been
processed. Call waitForInitialCreate() to ensure.");
             this.data.set(Arrays.copyOf(data, data.length));
    --- End diff --
    
    Isn't this potentially going to break legacy clients depending on how they handle exceptions
thrown from this method?


> Race in PersistentNode startup
> ------------------------------
>
>                 Key: CURATOR-310
>                 URL: https://issues.apache.org/jira/browse/CURATOR-310
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.10.0
>            Reporter: Gerd Behrmann
>
> We ran into what looks like a race in PersisentNode startup:
> java.lang.IllegalArgumentException: Path cannot be null
>         at org.apache.curator.utils.PathUtils.validatePath(PathUtils.java:48) ~[curator-client-2.10.0.jar:na]
>         at org.apache.curator.utils.PathUtils.validatePath(PathUtils.java:37) ~[curator-client-2.10.0.jar:na]
>         at org.apache.curator.utils.ZKPaths.fixForNamespace(ZKPaths.java:105) ~[curator-client-2.10.0.jar:na]
>         at org.apache.curator.framework.imps.NamespaceImpl.fixForNamespace(NamespaceImpl.java:104)
~[curator-framework-2.10.0.jar:na]
>         at org.apache.curator.framework.imps.CuratorFrameworkImpl.fixForNamespace(CuratorFrameworkImpl.java:594)
~[curator-framework-2.10.0.jar:na]
>         at org.apache.curator.framework.imps.SetDataBuilderImpl.forPath(SetDataBuilderImpl.java:244)
~[curator-framework-2.10.0.jar:na]
>         at org.apache.curator.framework.imps.SetDataBuilderImpl.forPath(SetDataBuilderImpl.java:41)
~[curator-framework-2.10.0.jar:na]
>         at dmg.cells.zookeeper.CellCuratorFramework$PathAndBytesableDecorator.forPath(CellCuratorFramework.java:1369)
~[cells-2.16.0-SNAPSHOT.jar:2.16.0-SNAPSHOT]
>         at org.apache.curator.framework.recipes.nodes.PersistentNode.setData(PersistentNode.java:323)
~[curator-recipes-2.10.0.jar:na]
> The problem here is that PersistentNode#setData calls PersistentNode#getActualPath, however
the nodePath field accessed by PersistentNode#getActualPath isn't set until PersistentNode#processBackgroundCallback
is called as a result of the createNode call in PersistentNode#start. 
> I.e. if one calls PersistentNode#setData right after calling start, there is a race between
the node creation initializing the actual path and PersistentNode#setData accessing it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message