[
https://issues.apache.org/jira/browse/CURATOR-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505938#comment-14505938
]
ASF GitHub Bot commented on CURATOR-154:
----------------------------------------
Github user madrob commented on the pull request:
https://github.com/apache/curator/pull/50#issuecomment-94962890
Not a committer, but +1, LGTM.
> PersistentEphemeralNode May Fail to Apply Updated Data
> ------------------------------------------------------
>
> Key: CURATOR-154
> URL: https://issues.apache.org/jira/browse/CURATOR-154
> 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
(v6.3.4#6332)
