[
https://issues.apache.org/jira/browse/YARN-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546654#comment-16546654
]
Allen Wittenauer commented on YARN-8536:
----------------------------------------
bq. friendly to legacy scripts.
Adding a new var doesn't help legacy scripts since the var didn't exist before
for them to use....
bq. Shouldn't hurt right?
It does in a variety of ways:
1) Done properly, every config variable adds at least 10 lines of bash and 5
lines of DOS batch. (and that's not counting src/site documentation, assuming
that contributors even bother). That makes it a long-term support burden for
just a bit of syntactic sugar.
2) There is already _OPTS to tune JVMs. If _HEAPSIZE is used and _OPTS is
used, where should the Xmx value come from? Prior to the work I did in
HADOOP-9902, this wasn't implemented consistently nor was it obvious to the
end user which one took precedence.
3) This is a slippery slope. Why should Xmx be the only JVM param with a
custom variable?
4) Before it gets said, I don't buy the "easier for end users" argument either.
In production scenarios, daemons almost always need additional parameters
above and beyond heap (gc logging, etc). So _OPTS gets defined anyway.
Long-term, we'd be better served to remove the _HEAPSIZE variables and to
standardize on _OPTS. It would greatly cut back on a lot of excess code and
make it absolutely clear to users that _OPTS is where all JVM tuning should go.
> Add max heap config option for Federation Router
> ------------------------------------------------
>
> Key: YARN-8536
> URL: https://issues.apache.org/jira/browse/YARN-8536
> Project: Hadoop YARN
> Issue Type: Task
> Reporter: Botong Huang
> Assignee: Botong Huang
> Priority: Minor
> Attachments: YARN-8536.v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
