zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Szecsi (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (ZOOKEEPER-3361) Add multi version of getChildren request
Date Thu, 01 Aug 2019 20:19:00 GMT

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Peter Szecsi resolved ZOOKEEPER-3361.
      Resolution: Won't Do
    Release Note: ZOOKEEPER-3402 already implemented a more general approach which solves
this issue as well.

> Add multi version of getChildren request
> ----------------------------------------
>                 Key: ZOOKEEPER-3361
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3361
>             Project: ZooKeeper
>          Issue Type: Sub-task
>          Components: java client, server, tests
>            Reporter: Peter Szecsi
>            Assignee: Peter Szecsi
>            Priority: Minor
>              Labels: pull-request-available
>   Original Estimate: 336h
>          Time Spent: 4.5h
>  Remaining Estimate: 331.5h
> There is already a multi operation for \{{delete, create, setData}}... However, \{{getChildren}}
has no version of getting the children of multiple nodes by one message.
> This could heavily improve the efficiency of a traversal (e.g. breadth-first search)
when the latency is high (>1ms). In this case, a simple \{{deleteAll}} algorithm on 10k
nodes takes at least (1ms * 10000 * 2 =) 20 sec, only to acquire the list of the nodes selected
for deleting (it has to check for every node whether it has children or not).
> I would add a version of \{{getChildren}} function to the ZooKeeper API which accepts
lists as well (containing node paths) and returns their children and introduce a new request
type. This way the backward compabilty would not be hurt but ZK could provide a more robust
solution for those who may have latency issues.

This message was sent by Atlassian JIRA

View raw message