zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ZOOKEEPER-3361) Add multi version of getChildren request
Date Fri, 26 Apr 2019 00:31:00 GMT

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

ASF GitHub Bot updated ZOOKEEPER-3361:
--------------------------------------
    Labels: pull-request-available  (was: )

> Add multi version of getChildren request
> ----------------------------------------
>
>                 Key: ZOOKEEPER-3361
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3361
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: java client, server, tests
>            Reporter: Peter Szecsi
>            Assignee: Peter Szecsi
>            Priority: Minor
>              Labels: pull-request-available
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> 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