curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CURATOR-154) PersistentEphemeralNode May Fail to Apply Updated Data
Date Tue, 21 Apr 2015 22:37:58 GMT


ASF GitHub Bot commented on CURATOR-154:

Github user madrob commented on the pull request:
    Not a committer, but +1, LGTM.

> PersistentEphemeralNode May Fail to Apply Updated Data
> ------------------------------------------------------
>                 Key: CURATOR-154
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.5.0
>         Environment: Dev Box: Windows 7, JDK 1.7.0_40, ZooKeeper 3.4.6 (single server)
>            Reporter: Matt Briggs
>            Assignee: Cameron McKenzie
> Steps to Reproduce:
> 1. Establish an ephemeral znode using PersistentEphemeralNode via a test app.
> 2. Invoke PersistentEphemeralNode.setData with an updated data value that is different
than the data originall provided to the PersistentEphemeralNode constructor.
> 3. Manually force a disconnect from ZooKeeper.  One way to achieve this is to set a breakpoint
in SetDataBuilderImpl.performBackgroundOperation before setData is physically launched, take
down the ZooKeeper server, then resume the test app.
> 4. Restart the ZooKeeper server before the test app's session has expired.
> 5. Observe that PersistentEphemeralNode will attempt to create the znode again on reconnect,
however it will encounter a NODEEXISTS error and leave whatever data was there intact.
> 6. Ultimately it appears like the updated data captured by the original setData call
will not be published to the znode unless the znode is deleted (e.g. by a session expiration).
> The hope was that the updated data would be applied at reconnect time.
> Stepping back, I'm also wondering if PersistentEphemeralNode should be more aggressive
in the setting of data.  setData for instance appears to giveup (aside from normal Curator
framework retry attempts) if it encounters an error, whereas createNode's callback will continue
to issue createNode calls on errors (other than NODEEXISTS).  Also, it appears that if I supply
the PersistentEphemeralNode constructor with initial data and the createNode call encounters
an existing znode, then my initial data won't be applied.

This message was sent by Atlassian JIRA

View raw message