Hadoop QA commented on YARN-3469:

{color:red}-1 overall{color}.  Here are the results of testing the latest 
  against trunk revision 6495940.

    {color:green}+1 @author{color}.  The patch does not contain any @author 

    {color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
                        Please justify why no new tests are needed for this 
                        Also please list what manual steps were performed to 
verify this patch.

    {color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

    {color:green}+1 javadoc{color}.  There were no new javadoc warning messages.

    {color:green}+1 eclipse:eclipse{color}.  The patch built with 

    {color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

    {color:green}+1 core tests{color}.  The patch passed unit tests in 

Test results: 
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/7271//console

This message is automatically generated.

> Do not set watch for most cases in ZKRMStateStore
> -------------------------------------------------
>                 Key: YARN-3469
>                 URL: https://issues.apache.org/jira/browse/YARN-3469
>             Project: Hadoop YARN
>          Issue Type: Improvement
>    Affects Versions: 2.6.0
>            Reporter: Jun Gong
>            Assignee: Jun Gong
>            Priority: Minor
>         Attachments: YARN-3469.01.patch
> In ZKRMStateStore, most operations(e.g. getDataWithRetries, 
> getDataWithRetries, getDataWithRetries) set watches on znode. Large watches 
> will cause problem such as [ZOOKEEPER-706: large numbers of watches can cause 
> session re-establishment to 
> fail|https://issues.apache.org/jira/browse/ZOOKEEPER-706].  
> Although there is a workaround that setting jute.maxbuffer to a larger value, 
> we need to adjust this value once there are more app and attempts stored in 
> ZK. And those watches are useless now. It might be better that do not set 
> watches.

This message was sent by Atlassian JIRA

Reply via email to