[ https://issues.apache.org/jira/browse/CURATOR-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16361365#comment-16361365 ]
ASF GitHub Bot commented on CURATOR-447: ---------------------------------------- Github user dragonsinth commented on a diff in the pull request: https://github.com/apache/curator/pull/250#discussion_r167668989 --- Diff: curator-recipes/src/main/java/org/apache/curator/framework/recipes/cache/TreeCache.java --- @@ -377,15 +375,16 @@ public void processResult(CuratorFramework client, CuratorEvent event) throws Ex Preconditions.checkState(parent == null, "unexpected EXISTS on non-root node"); if ( event.getResultCode() == KeeperException.Code.OK.intValue() ) { - nodeStateUpdater.compareAndSet(this, NodeState.DEAD, NodeState.PENDING); + childDataUpdater.compareAndSet(this, DEAD, null); wasCreated(); } break; case CHILDREN: if ( event.getResultCode() == KeeperException.Code.OK.intValue() ) { ChildData oldChildData = childData; - if ( oldChildData != null && oldChildData.getStat().getMzxid() == newStat.getMzxid() ) + //TODO consider doing update of cversion, pzxid, numChildren only --- End diff -- seems reasonable to me > TreeCache: Improve memory usage and concurrent update logic > ----------------------------------------------------------- > > Key: CURATOR-447 > URL: https://issues.apache.org/jira/browse/CURATOR-447 > Project: Apache Curator > Issue Type: Improvement > Components: Recipes > Affects Versions: 3.3.0, 2.12.0 > Reporter: Nick Hill > Priority: Minor > Labels: performance > > Jira https://issues.apache.org/jira/browse/CURATOR-374 reduced per-node > memory usage in {{TreeCache}}. It can be improved further via removal of the > {{nodeState}} field - its {{LIVE}} state corresponds exactly to the adjacent > {{childData}} field being non-null, and a sentinel {{ChildData}} value can be > used for the {{DEAD}} state. This simplification also reduces the room for > bugs and state inconsistencies. > Other improvements included: > * A further simplification to have {{TreeNode}} extend {{AtomicReference}}, > which obviates the need for an explicit {{childData}} field > * More robust cache update logic (in get-children and get-data event > callbacks) > * Avoid overhead of incrementing/decrementing the {{outstandingOps}} atomic > integer post-initialization -- This message was sent by Atlassian JIRA (v7.6.3#76005)