[
https://issues.apache.org/jira/browse/YARN-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009995#comment-16009995
]
Chuan Jin commented on YARN-3469:
---------------------------------
Our cluster uses 2.7.3 branch which merges the Curator related codes from 2.8.0
branch, but we still encounter this problem. I also notice the
[-ZOOKEEPER-706-|https://issues.apache.org/jira/browse/ZOOKEEPER-706] , and
replace the old zookeeper jar(3.4.6) to a newer one(3.4.10). It does solve my
problem.
I think it's a good reason to update the zookeeper version in hadoop trunk.
> ZKRMStateStore: Avoid setting watches that are not required
> -----------------------------------------------------------
>
> 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
> Fix For: 2.8.0, 2.7.1, 3.0.0-alpha1
>
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
