[jira] [Commented] (YARN-3104) RM continues to send new AMRM tokens every heartbeat between rolling and activation
[ https://issues.apache.org/jira/browse/YARN-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14297633#comment-14297633 ] Jason Lowe commented on YARN-3104: -- Test failure is unrelated, see YARN-1778. RM continues to send new AMRM tokens every heartbeat between rolling and activation --- Key: YARN-3104 URL: https://issues.apache.org/jira/browse/YARN-3104 Project: Hadoop YARN Issue Type: Bug Components: resourcemanager Affects Versions: 2.6.0 Reporter: Jason Lowe Assignee: Jason Lowe Attachments: YARN-3104.001.patch When the RM rolls a new AMRM secret, it conveys this to the AMs when it notices they are still connected with the old key. However neither the RM nor the AM explicitly close the connection or otherwise try to reconnect with the new secret. Therefore the RM keeps thinking the AM doesn't have the new token on every heartbeat and keeps sending new tokens for the period between the key roll and the key activation. Once activated the RM no longer squawks in its logs about needing to generate a new token every heartbeat (i.e.: second) for every app, but the apps can still be using the old token. The token is only checked upon connection to the RM. The apps don't reconnect when sent a new token, and the RM doesn't force them to reconnect by closing the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-3104) RM continues to send new AMRM tokens every heartbeat between rolling and activation
[
https://issues.apache.org/jira/browse/YARN-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298028#comment-14298028
]
Jian He commented on YARN-3104:
---
Trying to understand this, do you mean once the connection is authenticated,
take MapReduce as an example, even if MapReduce AM gets the new token and add
the new token into its ugi. But because the connection will not
re-authenticate, it always uses the old token for this comparison
{{nextMasterKey.getMasterKey().getKeyId() != amrmTokenIdentifier.getKeyId()}}
which leads to RM keep sending new tokens ?
RM continues to send new AMRM tokens every heartbeat between rolling and
activation
---
Key: YARN-3104
URL: https://issues.apache.org/jira/browse/YARN-3104
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 2.6.0
Reporter: Jason Lowe
Assignee: Jason Lowe
Attachments: YARN-3104.001.patch
When the RM rolls a new AMRM secret, it conveys this to the AMs when it
notices they are still connected with the old key. However neither the RM
nor the AM explicitly close the connection or otherwise try to reconnect with
the new secret. Therefore the RM keeps thinking the AM doesn't have the new
token on every heartbeat and keeps sending new tokens for the period between
the key roll and the key activation. Once activated the RM no longer squawks
in its logs about needing to generate a new token every heartbeat (i.e.:
second) for every app, but the apps can still be using the old token. The
token is only checked upon connection to the RM. The apps don't reconnect
when sent a new token, and the RM doesn't force them to reconnect by closing
the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YARN-3104) RM continues to send new AMRM tokens every heartbeat between rolling and activation
[
https://issues.apache.org/jira/browse/YARN-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296013#comment-14296013
]
Hadoop QA commented on YARN-3104:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12695094/YARN-3104.001.patch
against trunk revision caf7298.
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
org.apache.hadoop.yarn.server.resourcemanager.recovery.TestFSRMStateStore
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/6442//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/6442//console
This message is automatically generated.
RM continues to send new AMRM tokens every heartbeat between rolling and
activation
---
Key: YARN-3104
URL: https://issues.apache.org/jira/browse/YARN-3104
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 2.6.0
Reporter: Jason Lowe
Assignee: Jason Lowe
Attachments: YARN-3104.001.patch
When the RM rolls a new AMRM secret, it conveys this to the AMs when it
notices they are still connected with the old key. However neither the RM
nor the AM explicitly close the connection or otherwise try to reconnect with
the new secret. Therefore the RM keeps thinking the AM doesn't have the new
token on every heartbeat and keeps sending new tokens for the period between
the key roll and the key activation. Once activated the RM no longer squawks
in its logs about needing to generate a new token every heartbeat (i.e.:
second) for every app, but the apps can still be using the old token. The
token is only checked upon connection to the RM. The apps don't reconnect
when sent a new token, and the RM doesn't force them to reconnect by closing
the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
