curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cameron McKenzie (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-310) Race in PersistentNode startup
Date Fri, 18 Mar 2016 02:20:33 GMT

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

Cameron McKenzie commented on CURATOR-310:
------------------------------------------

Your assessment seems correct to me. There's definitely a race condition there.

I guess one option is to block on initialCreateLatch in the setData() method. This may not
be desirable though as it will potentially make this method block indefinitely. Other option
is to block in a separate thread, but it's a bit ugly to have to introduce this for an edge
case like this.

> 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