curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Briggs (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CURATOR-154) PersistentEphemeralNode May Fail to Apply Updated Data
Date Mon, 20 Oct 2014 15:55:34 GMT
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)

Mime
View raw message