zookeeper-dev mailing list archives

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

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

Peter Szecsi updated ZOOKEEPER-3361:
------------------------------------
    Issue Type: Sub-task  (was: Improvement)
        Parent: ZOOKEEPER-1407

> 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: 1h
>  Remaining Estimate: 335h
>
> 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
(v7.6.3#76005)

Mime
View raw message