hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-6125) The application attempt's diagnostic message should have a maximum size
Date Fri, 03 Feb 2017 14:32:52 GMT

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

Jason Lowe commented on YARN-6125:
----------------------------------

I think it's not necessary to distinguish between message truncation and overall truncation.
 We can simply tack on a header stating the diagnostics were truncated when reporting.  For
example, "Application diagnostics too large, only showing the last N bytes:"  A potentially
useful enhancement could be to track the total number of diagnostics bytes even though we're
not keeping all those bytes around, e.g.: "App diagnostics too large, only showing last N
bytes of T bytes total:"  We may have to do something similar anyway to know when the diagnostics
were truncated.

> 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
>
>
> 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


Mime
View raw message