Matt Briggs created CURATOR-154:
-----------------------------------
Summary: 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
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)
