[jira] [Commented] (YARN-10001) Add explanation of unimplemented methods in InMemoryConfigurationStore
[ https://issues.apache.org/jira/browse/YARN-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064473#comment-17064473 ] Siddharth Ahuja commented on YARN-10001: Hi [~snemeth], I have added explanations for methods that have no implementation - _checkVersion, storeVersion_ and that return a null (i.e. methods that do nothing) - _getCurrentVersion, getConfStoreVersion, getLogs, getConfirmedConfHistory._ Kindly let me know if you are ok with the descriptions (+cc [~wilfreds]). > Add explanation of unimplemented methods in InMemoryConfigurationStore > -- > > Key: YARN-10001 > URL: https://issues.apache.org/jira/browse/YARN-10001 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Szilard Nemeth >Assignee: Siddharth Ahuja >Priority: Major > Attachments: YARN-10001.001.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Resolved] (YARN-10205) NodeManager stateful restart feature did not work as expected - information only (Resolved)
[
https://issues.apache.org/jira/browse/YARN-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anil Sadineni resolved YARN-10205.
--
Resolution: Not A Problem
> NodeManager stateful restart feature did not work as expected - information
> only (Resolved)
> ---
>
> Key: YARN-10205
> URL: https://issues.apache.org/jira/browse/YARN-10205
> Project: Hadoop YARN
> Issue Type: Test
> Components: graceful, nodemanager, rolling upgrade, yarn
>Reporter: Anil Sadineni
>Priority: Major
>
> *TL;DR* This is information only Jira on stateful restart of node manager
> feature. Unexpected behavior of this feature was due to systemd process
> configurations in this case. Please read below for more details -
> Stateful restart of Node Manager(YARN-1336) i introduced in Hadoop 2.6. This
> feature worked as expected in Hadoop 2.6 for us. Recently we upgraded our
> clusters from 2.6 to 2.9.2 along with some OS upgrades. This feature was
> broken after the upgrade. one of the initial suspicion was
> LinuxContainerExecutor as we started using it in this upgrade.
> yarn-site.xml has all required configurations to enable this feature -
> {{yarn.nodemanager.recovery.enabled: 'true'}}
> {{yarn.nodemanager.recovery.dir:''}}
> {{yarn.nodemanager.recovery.supervised: 'true'}}
> {{yarn.nodemanager.address: '0.0.0.0:8041'}}
> While containers running and NM restarted, below is the exception constantly
> observed in Node Manager logs -
> {quote}
> java.io.IOException: *Timeout while waiting for exit code from
> container_e37_1583181000856_0008_01_43*2020-03-05 17:45:18,241 ERROR
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
> Unable to recover container container_e37_1583181000856_0008_01_43
> {quote}
> {quote}at
> org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor.reacquireContainer(ContainerExecutor.java:274)
> at
> org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor.reacquireContainer(LinuxContainerExecutor.java:631)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:84)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:47)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2020-03-05 17:45:18,241 ERROR
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
> Unable to recover container container_e37_1583181000856_0008_01_18
> java.io.IOException: Timeout while waiting for exit code from
> container_e37_1583181000856_0008_01_18
> at
> org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor.reacquireContainer(ContainerExecutor.java:274)
> at
> org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor.reacquireContainer(LinuxContainerExecutor.java:631)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:84)
> at
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:47)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2020-03-05 17:45:18,242 WARN
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
> Recovered container exited with a non-zero exit code 154
> {quote}
> {quote}2020-03-05 17:45:18,243 WARN
> org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
> Recovered container exited with a non-zero exit code 154
> {quote}
> After some digging on what was causing exitfile missing, at OS level
> identified that running container processes are going down as soon as NM is
> going down. Process tree looks perfectly fine as the container-executor takes
> care of forking child process as expected. Dig deeper into various parts of
> code to see if anything caused the failure.
> One question was did we break anything in our internal repo after we forked
> 2.9.2 from open source. Started looking into code at different areas like NM
> shutdown
[jira] [Created] (YARN-10205) NodeManager stateful restart feature did not work as expected - information only (Resolved)
Anil Sadineni created YARN-10205:
Summary: NodeManager stateful restart feature did not work as
expected - information only (Resolved)
Key: YARN-10205
URL: https://issues.apache.org/jira/browse/YARN-10205
Project: Hadoop YARN
Issue Type: Test
Components: graceful, nodemanager, rolling upgrade, yarn
Reporter: Anil Sadineni
*TL;DR* This is information only Jira on stateful restart of node manager
feature. Unexpected behavior of this feature was due to systemd process
configurations in this case. Please read below for more details -
Stateful restart of Node Manager(YARN-1336) i introduced in Hadoop 2.6. This
feature worked as expected in Hadoop 2.6 for us. Recently we upgraded our
clusters from 2.6 to 2.9.2 along with some OS upgrades. This feature was broken
after the upgrade. one of the initial suspicion was LinuxContainerExecutor as
we started using it in this upgrade.
yarn-site.xml has all required configurations to enable this feature -
{{yarn.nodemanager.recovery.enabled: 'true'}}
{{yarn.nodemanager.recovery.dir:''}}
{{yarn.nodemanager.recovery.supervised: 'true'}}
{{yarn.nodemanager.address: '0.0.0.0:8041'}}
While containers running and NM restarted, below is the exception constantly
observed in Node Manager logs -
{quote}
java.io.IOException: *Timeout while waiting for exit code from
container_e37_1583181000856_0008_01_43*2020-03-05 17:45:18,241 ERROR
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
Unable to recover container container_e37_1583181000856_0008_01_43
{quote}
{quote}at
org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor.reacquireContainer(ContainerExecutor.java:274)
at
org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor.reacquireContainer(LinuxContainerExecutor.java:631)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:84)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:47)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2020-03-05 17:45:18,241 ERROR
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
Unable to recover container container_e37_1583181000856_0008_01_18
java.io.IOException: Timeout while waiting for exit code from
container_e37_1583181000856_0008_01_18
at
org.apache.hadoop.yarn.server.nodemanager.ContainerExecutor.reacquireContainer(ContainerExecutor.java:274)
at
org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor.reacquireContainer(LinuxContainerExecutor.java:631)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:84)
at
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch.call(RecoveredContainerLaunch.java:47)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2020-03-05 17:45:18,242 WARN
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
Recovered container exited with a non-zero exit code 154
{quote}
{quote}2020-03-05 17:45:18,243 WARN
org.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.RecoveredContainerLaunch:
Recovered container exited with a non-zero exit code 154
{quote}
After some digging on what was causing exitfile missing, at OS level identified
that running container processes are going down as soon as NM is going down.
Process tree looks perfectly fine as the container-executor takes care of
forking child process as expected. Dig deeper into various parts of code to
see if anything caused the failure.
One question was did we break anything in our internal repo after we forked
2.9.2 from open source. Started looking into code at different areas like NM
shutdown hook and clean up process, NM State store on container launch, NM aux
services, container-executor, Shell launch and clean up related hooks, etc.
Things were looking fine as expected.
It was identified that hadoop-nodemanager systemd process configured to use
default KillMode which is control-group.
[https://www.freedesktop.org/software/systemd/man/systemd.kill.html#KillMode=]
This is causing
[jira] [Commented] (YARN-10077) Region in ats-hbase table 'prod.timelineservice.entity' failing to split
[
https://issues.apache.org/jira/browse/YARN-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064461#comment-17064461
]
Anil Sadineni commented on YARN-10077:
--
We are having the same issue with both entity and application tables. In our
case, there are many clusters. Loads for each cluster are so huge that regions
are getting overloaded without getting split in this policy for application
table as well.
I believe we need another flexibility region split policy which is similar to
DelimitedKeyPrefixRegionSplitPolicy but gives flexibility to provide the
ordinance of delimiter. Here is java doc for the custom region split policy
that I am thinking -
{quote}_/**_
_* A custom RegionSplitPolicy implementing a SplitPolicy that groups_ _rows by
a prefix of the row-key with a delimiter and its nth ordinal._
_* This ensures that a region is not split "inside" a prefix of a row key. I.e.
rows can be co-located in a region by their_
_* prefix._
_* As an example, if you have row keys delimited with_ ___!,
like_
_*_ ___userid!clusterid!flowname!flowid___
_*_
_*_ __
_*_ ___use prefix delimiter ! and nth ordinal as 2, this split policy
ensures that all rows starting with_
_* the same userid and clusterid belongs to the same region.
(userid!clusterid)___
_*_ ___use prefix delimiter ! and nth ordinal as 3, this split policy
ensures that all rows starting with_
_* the same userid, clusterid and flowename belongs to the same region.
(userid!clusterid!flowname)___
_*_ __
_*/_
{quote}
I will open hbase jira for this new policy. Please let me know your
thoughts/feedback on this.
> Region in ats-hbase table 'prod.timelineservice.entity' failing to split
>
>
> Key: YARN-10077
> URL: https://issues.apache.org/jira/browse/YARN-10077
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: ATSv2
>Affects Versions: 3.3.0
>Reporter: Prabhu Joseph
>Priority: Major
>
> Entity Table grows too large very quickly and the table is failing to split
> when most of the entity rows belongs to an user.
> # Need to set optimal TTL value for info and config column family
> # Need to increase the prefix length for KeyPrefixRegionSplitPolicy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (YARN-10075) historyContext doesn't need to be a class attribute inside JobHistoryServer
[ https://issues.apache.org/jira/browse/YARN-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064176#comment-17064176 ] Siddharth Ahuja edited comment on YARN-10075 at 3/22/20, 9:24 AM: -- Just uploaded a patch that does the following: # Removed "protected" attribute - _historyContext_ from JobHistoryServer. Only usage of historyContext in the class was to be passed in as an argument during the instantiation of the HistoryClientService and nothing else. Therefore, it is now cleaned up and the HistoryClientService is now instantiated by casting the jobHistoryService with HistoryContext. # One test class - _TestJHSSecurity_ was found to be abusing this protected attribute during the creation of a jobHistoryServer inside this test class. The historyContext attribute was being referenced directly (bad) inside createHistoryClientService method during creation of the mock job history server. In fact, the only use of implementing this helper method seems to be passing in the "custom" jhsDTSecretManager (JHSDelegationTokenSecretManager) during the creation of the history client service. However, this is not required because jobHistoryServer.init(conf) will result in the same due to the serviceInit() call within JobHistoryServer that will call createHistoryClientService() which will end up using the custom jhsDTSecretManager created just earlier (createJHSSecretManager(...,...) happens before createHistoryClientService()). # Removed a commented out line - _final JobHistoryServer jobHistoryServer = jhServer;_ from the test class as it was near the code that was being cleaned up in 2. was (Author: sahuja): Just uploaded a patch that does the following: # Removed "protected" attribute - _historyContext_ from JobHistoryServer. Only usage of historyContext in the class was to be passed in as an argument during the instantiation of the HistoryClientService and nothing else. Therefore, it is now cleaned up and the HistoryClientService is now instantiated by casting the jobHistoryService with HistoryContext. # One test class - _TestJHSSecurity_ was found to be abusing this protected attribute during the creation of a jobHistoryServer inside this test class. The historyContext attribute was being referenced directly (bad) inside createHistoryClientService method during creation of the mock job history server. In fact, the only use of implementing this helper method seems to be passing in the "custom" jhsDTSecretManager (JHSDelegationTokenSecretManager) during the creation of the history client service. However, this is not required because jobHistoryServer.init(conf) will result in the same due to the serviceInit() call within JobHistoryServer that will call createHistoryClientService() which will end up using the custom jhsDTSecretManager created just earlier (createJHSSecretManager(...,...) happens before createHistoryClientService()). # Removed a commented out line - _final JobHistoryServer jobHistoryServer = jhServer;_ from the test class. > historyContext doesn't need to be a class attribute inside JobHistoryServer > --- > > Key: YARN-10075 > URL: https://issues.apache.org/jira/browse/YARN-10075 > Project: Hadoop YARN > Issue Type: Improvement > Components: yarn >Reporter: Siddharth Ahuja >Assignee: Siddharth Ahuja >Priority: Minor > Attachments: YARN-10075.001.patch > > > "historyContext" class attribute at > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L67 > is assigned a cast of another class attribute - "jobHistoryService" - > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L131, > however it does not need to be stored separately because it is only ever > used once in the clas, and that too as an argument while instantiating the > HistoryClientService class at > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L155. > Therefore, we could just delete the lines at > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L67 > and > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L131 > completely and
[jira] [Comment Edited] (YARN-10075) historyContext doesn't need to be a class attribute inside JobHistoryServer
[ https://issues.apache.org/jira/browse/YARN-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064176#comment-17064176 ] Siddharth Ahuja edited comment on YARN-10075 at 3/22/20, 9:23 AM: -- Just uploaded a patch that does the following: # Removed "protected" attribute - _historyContext_ from JobHistoryServer. Only usage of historyContext in the class was to be passed in as an argument during the instantiation of the HistoryClientService and nothing else. Therefore, it is now cleaned up and the HistoryClientService is now instantiated by casting the jobHistoryService with HistoryContext. # One test class - _TestJHSSecurity_ was found to be abusing this protected attribute during the creation of a jobHistoryServer inside this test class. The historyContext attribute was being referenced directly (bad) inside createHistoryClientService method during creation of the mock job history server. In fact, the only use of implementing this helper method seems to be passing in the "custom" jhsDTSecretManager (JHSDelegationTokenSecretManager) during the creation of the history client service. However, this is not required because jobHistoryServer.init(conf) will result in the same due to the serviceInit() call within JobHistoryServer that will call createHistoryClientService() which will end up using the custom jhsDTSecretManager created just earlier (createJHSSecretManager(...,...) happens before createHistoryClientService()). # Removed a commented out line - _final JobHistoryServer jobHistoryServer = jhServer;_ from the test class. was (Author: sahuja): Just uploaded a patch that does the following: # Removed "protected" attribute - _historyContext_ from JobHistoryServer. Only usage of historyContext in the class was to be passed in as an argument during the instantiation of the HistoryClientService and nothing else. Therefore, it is now cleaned up and the HistoryClientService is now instantiated by casting the jobHistoryService with HistoryContext. # One test class - _TestJHSSecurity_ was found to be abusing this protected attribute during the creation of a jobHistoryServer inside this test class. The historyContext attribute was being referenced directly (bad) inside createHistoryClientService method during creation of the mock job history server. In fact, the only use of implementing this helper method seems to be passing in the "custom" jhsDTSecretManager (JHSDelegationTokenSecretManager) during the creation of the history client service. However, this is not required because jobHistoryServer.init(conf) will result in the same due to the serviceInit() call within JobHistoryServer that will call createHistoryClientService() which will end up using the custom jhsDTSecretManager created just earlier (createJHSSecretManager(...,...) happens before createHistoryClientService()). # Cleaned up an unused commented line - _final JobHistoryServer jobHistoryServer = jhServer;_ from the test class. > historyContext doesn't need to be a class attribute inside JobHistoryServer > --- > > Key: YARN-10075 > URL: https://issues.apache.org/jira/browse/YARN-10075 > Project: Hadoop YARN > Issue Type: Improvement > Components: yarn >Reporter: Siddharth Ahuja >Assignee: Siddharth Ahuja >Priority: Minor > Attachments: YARN-10075.001.patch > > > "historyContext" class attribute at > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L67 > is assigned a cast of another class attribute - "jobHistoryService" - > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L131, > however it does not need to be stored separately because it is only ever > used once in the clas, and that too as an argument while instantiating the > HistoryClientService class at > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L155. > Therefore, we could just delete the lines at > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L67 > and > https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L131 > completely and instantiate the HistoryClientService as follows:
[jira] [Commented] (YARN-10075) historyContext doesn't need to be a class attribute inside JobHistoryServer
[
https://issues.apache.org/jira/browse/YARN-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064176#comment-17064176
]
Siddharth Ahuja commented on YARN-10075:
Just uploaded a patch that does the following:
# Removed "protected" attribute - _historyContext_ from JobHistoryServer. Only
usage of historyContext in the class was to be passed in as an argument during
the instantiation of the HistoryClientService and nothing else. Therefore, it
is now cleaned up and the HistoryClientService is now instantiated by casting
the jobHistoryService with HistoryContext.
# One test class - _TestJHSSecurity_ was found to be abusing this protected
attribute during the creation of a jobHistoryServer inside this test class. The
historyContext attribute was being referenced directly (bad) inside
createHistoryClientService method during creation of the mock job history
server. In fact, the only use of implementing this helper method seems to be
passing in the "custom" jhsDTSecretManager (JHSDelegationTokenSecretManager)
during the creation of the history client service. However, this is not
required because jobHistoryServer.init(conf) will result in the same due to the
serviceInit() call within JobHistoryServer that will call
createHistoryClientService() which will end up using the custom
jhsDTSecretManager created just earlier (createJHSSecretManager(...,...)
happens before createHistoryClientService()).
# Cleaned up an unused commented line - _final JobHistoryServer
jobHistoryServer = jhServer;_ from the test class.
> historyContext doesn't need to be a class attribute inside JobHistoryServer
> ---
>
> Key: YARN-10075
> URL: https://issues.apache.org/jira/browse/YARN-10075
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: yarn
>Reporter: Siddharth Ahuja
>Assignee: Siddharth Ahuja
>Priority: Minor
> Attachments: YARN-10075.001.patch
>
>
> "historyContext" class attribute at
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L67
> is assigned a cast of another class attribute - "jobHistoryService" -
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L131,
> however it does not need to be stored separately because it is only ever
> used once in the clas, and that too as an argument while instantiating the
> HistoryClientService class at
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L155.
> Therefore, we could just delete the lines at
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L67
> and
> https://github.com/apache/hadoop/blob/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/JobHistoryServer.java#L131
> completely and instantiate the HistoryClientService as follows:
> {code}
> @VisibleForTesting
> protected HistoryClientService createHistoryClientService() {
> return new HistoryClientService((HistoryContext)jobHistoryService,
> this.jhsDTSecretManager);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
