Details
Major Description
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.