curator-dev mailing list archives

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

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

Gerd Behrmann commented on CURATOR-310:
---------------------------------------

A more involved fix that doesn't suffer from additional blocking or extra threads is to latch
the setData onto the node creation callback. If calling setData while still initializing (as
indicated by initialCreateLatch) you skip setData on the node, but in the initialisationComplete
method you trigger a setData call to push any suppressed updates.

> 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