Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 11 Feb 2017 00:35:42 +0000 (UTC)
From: "Andras Piros (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13038215.1485454102000.53213.1486773342047@Atlassian.JIRA>
In-Reply-To: <JIRA.13038215.1485454102000@Atlassian.JIRA>
References: <JIRA.13038215.1485454102000@Atlassian.JIRA> <JIRA.13038215.1485454102108@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (YARN-6125) The application attempt's
 diagnostic message should have a maximum size
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 11 Feb 2017 00:35:48 -0000


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

Andras Piros edited comment on YARN-6125 at 2/11/17 12:34 AM:
--------------------------------------------------------------

[~templedf] latest code review comment responses:
# log and exception messages:
## done, except for {{"chars"}}
## done
## done
## see next one
# decided to use only {{append()}} and remove {{appendToDiagnosticsSafely()}}
# as we don't want to count message header and ellipses against {{limit}}, I'd stick to the current implementation as the header is of variable length. {{checkAndCut()}} can remain as simple as check whether {{messages}} would extend beyond {{limit}} or not
# done
# done. My original consideration was that we should distinguish between the current length (after truncate without header and ellipsis) and the total length. Anyway, renamed
# switched to {{"chars"}} also for docs and all messages


was (Author: andras.piros):
[~templedf] latest code review comment responses:
# log and exception messages:
## done, except for {{"chars"}}
## done
## done
## see next one
# decided to use only {{append()}} and remove {{appendToDiagnosticsSafely()}}
# as we don't want to count message header and ellipses, I'd stick to the current implementation as the header is of variable length. {{checkAndCut()}} can remain as simple as check whether {{messages}} would extend beyond {{limit}} or not
# done
# done. My original consideration was that we should distinguish between the current length (after truncate without header and ellipsis) and the total length. Anyway, renamed
# switched to {{"chars"}} also for docs and all messages

> The application attempt's diagnostic message should have a maximum size
> -----------------------------------------------------------------------
>
>                 Key: YARN-6125
>                 URL: https://issues.apache.org/jira/browse/YARN-6125
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: resourcemanager
>    Affects Versions: 2.7.0
>            Reporter: Daniel Templeton
>            Assignee: Andras Piros
>            Priority: Critical
>             Fix For: 3.0.0-alpha3
>
>         Attachments: YARN-6125.000.patch, YARN-6125.001.patch, YARN-6125.002.patch, YARN-6125.003.patch, YARN-6125.004.patch, YARN-6125.005.patch, YARN-6125.006.patch
>
>
> We've found through experience that the diagnostic message can grow unbounded.  I've seen attempts that have diagnostic messages over 1MB.  Since the message is stored in the state store, it's a bad idea to allow the message to grow unbounded.  Instead, there should be a property that sets a maximum size on the message.
> I suspect that some of the ZK state store issues we've seen in the past were due to the size of the diagnostic messages and not to the size of the classpath, as is the current prevailing opinion.
> An open question is how best to prune the message once it grows too large.  Should we
> # truncate the tail,
> # truncate the head,
> # truncate the middle,
> # add another property to make the behavior selectable, or
> # none of the above?


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org