[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372554#comment-17372554
 ] 

Emil Kleszcz commented on ZOOKEEPER-4332:
-----------------------------------------

Hi Damien,

Thanks for all your prompt and detailed answers. I really appreciate this. I 
can back-port the patch or upgrade ZK to get pagination. Also, there is an 
option to solve this issue by applying indexing for the Yarn managed jobs that 
are maintained under this specific path. However, my current problem is to 
clean up this state. I cannot do anything with this path as I explained. At the 
moment, I cannot even check the content of the path so cannot tell you what is 
the exact length but it should be this format: 
"application_1592399466874_18251" and no longer than in it there might be 
"appattempt_1592399466874_17986_000002".
Thus, 
"/rmstore/ZKRMStateRoot/RMAppRoot/application_1592399466874_18251/appattempt_1592399466874_17986_000002"
 should be the longest. The length in bytes should be 10601166. I was 
increasing jute.maxbuffer to a higher value. The extra dot is just my editorial 
mistake in the post, in zoo.cfg it is specified as expected: 
"jute.maxbuffer=4194304".




 

 

> Cannot access children of znode that owns too many znodes
> ---------------------------------------------------------
>
>                 Key: ZOOKEEPER-4332
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4332
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.6.1
>            Reporter: Emil Kleszcz
>            Priority: Critical
>              Labels: zookeeper
>         Attachments: Screen Shot 2021-06-30 at 16.52.17.png, Screen Shot 
> 2021-06-30 at 16.52.42.png, Screen Shot 2021-06-30 at 16.53.04.png
>
>
> We experience problems with performing any operation (deleteall, get etc.) on 
> a znode that has too many child nodes. In our case, it's above 200k. At the 
> same time jute.max.buffer is 4194304. Increasing it by a few factors doesn't 
> help. This should be either solved by limiting the number of direct znodes 
> allowed by a parameter or by adding a hard limit by default.
> I am attaching some screenshots of the commands and their results. What's 
> interesting the numbers from getAllChildrenNumber and stat (numChildren) 
> commands don't match.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to