[ https://issues.apache.org/jira/browse/YARN-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14359224#comment-14359224 ]
Hadoop QA commented on YARN-3336: --------------------------------- {color:red}-1 overall{color}. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12704208/YARN-3336.001.patch against trunk revision 06ce1d9. {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:red}-1 findbugs{color}. The patch appears to introduce 5 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.scheduler.capacity.TestCapacitySchedulerQueueACLs org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesFairScheduler org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesApps org.apache.hadoop.yarn.server.resourcemanager.security.TestAMRMTokens org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesCapacitySched org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServices org.apache.hadoop.yarn.server.resourcemanager.TestKillApplicationWithRMHA org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesNodeLabels org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesDelegationTokens org.apache.hadoop.yarn.server.resourcemanager.TestClientRMTokens org.apache.hadoop.yarn.server.resourcemanager.recovery.TestFSRMStateStore org.apache.hadoop.yarn.server.resourcemanager.TestAMAuthorization The following test timeouts occurred in hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager: org.apache.hadoop.yarn.server.resourcemanager.TestRMRestTestTests org.apache.hadoop.yarn.server.resourcemanager.TestAMAuthorizatTestTests org.apache.hadoop.yarn.server.resourcemanager.TestFifoScheTests org.apache.hadoop.yarn.server.resourcemanager.applicationsmanager.TestAMReTests org.apache.hadoop.yarn.server.resourcemanager.applicationsmanager.TestAMRMRPCRespoTests org.apache.hadoop.yarn.server.resourcemanager.TestContainerResourcTests org.apache.hadoop.yarn.server.resourcemanager.TestResourceManTests org.apache.hadoop.yarn.server.resourcemanager.security.TestClientToAMTokens org.apache.hadoop.yarn.server.resourcemanager.webapp.TestRMWebServicesAppsModification Test results: https://builds.apache.org/job/PreCommit-YARN-Build/6941//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-YARN-Build/6941//artifact/patchprocess/newPatchFindbugsWarningshadoop-yarn-server-resourcemanager.html Console output: https://builds.apache.org/job/PreCommit-YARN-Build/6941//console This message is automatically generated. > FileSystem memory leak in DelegationTokenRenewer > ------------------------------------------------ > > Key: YARN-3336 > URL: https://issues.apache.org/jira/browse/YARN-3336 > Project: Hadoop YARN > Issue Type: Bug > Components: resourcemanager > Reporter: zhihai xu > Assignee: zhihai xu > Priority: Critical > Attachments: YARN-3336.000.patch, YARN-3336.001.patch > > > FileSystem memory leak in DelegationTokenRenewer. > Every time DelegationTokenRenewer#obtainSystemTokensForUser is called, a new > FileSystem entry will be added to FileSystem#CACHE which will never be > garbage collected. > This is the implementation of obtainSystemTokensForUser: > {code} > protected Token<?>[] obtainSystemTokensForUser(String user, > final Credentials credentials) throws IOException, InterruptedException > { > // Get new hdfs tokens on behalf of this user > UserGroupInformation proxyUser = > UserGroupInformation.createProxyUser(user, > UserGroupInformation.getLoginUser()); > Token<?>[] newTokens = > proxyUser.doAs(new PrivilegedExceptionAction<Token<?>[]>() { > @Override > public Token<?>[] run() throws Exception { > return FileSystem.get(getConfig()).addDelegationTokens( > UserGroupInformation.getLoginUser().getUserName(), credentials); > } > }); > return newTokens; > } > {code} > The memory leak happened when FileSystem.get(getConfig()) is called with a > new proxy user. > Because createProxyUser will always create a new Subject. > The calling sequence is > FileSystem.get(getConfig())=>FileSystem.get(getDefaultUri(conf), > conf)=>FileSystem.CACHE.get(uri, conf)=>FileSystem.CACHE.getInternal(uri, > conf, key)=>FileSystem.CACHE.map.get(key)=>createFileSystem(uri, conf) > {code} > public static UserGroupInformation createProxyUser(String user, > UserGroupInformation realUser) { > if (user == null || user.isEmpty()) { > throw new IllegalArgumentException("Null user"); > } > if (realUser == null) { > throw new IllegalArgumentException("Null real user"); > } > Subject subject = new Subject(); > Set<Principal> principals = subject.getPrincipals(); > principals.add(new User(user)); > principals.add(new RealUser(realUser)); > UserGroupInformation result =new UserGroupInformation(subject); > result.setAuthenticationMethod(AuthenticationMethod.PROXY); > return result; > } > {code} > FileSystem#Cache#Key.equals will compare the ugi > {code} > Key(URI uri, Configuration conf, long unique) throws IOException { > scheme = uri.getScheme()==null?"":uri.getScheme().toLowerCase(); > authority = > uri.getAuthority()==null?"":uri.getAuthority().toLowerCase(); > this.unique = unique; > this.ugi = UserGroupInformation.getCurrentUser(); > } > public boolean equals(Object obj) { > if (obj == this) { > return true; > } > if (obj != null && obj instanceof Key) { > Key that = (Key)obj; > return isEqual(this.scheme, that.scheme) > && isEqual(this.authority, that.authority) > && isEqual(this.ugi, that.ugi) > && (this.unique == that.unique); > } > return false; > } > {code} > UserGroupInformation.equals will compare subject by reference. > {code} > public boolean equals(Object o) { > if (o == this) { > return true; > } else if (o == null || getClass() != o.getClass()) { > return false; > } else { > return subject == ((UserGroupInformation) o).subject; > } > } > {code} > So in this case, every time createProxyUser and FileSystem.get(getConfig()) > are called, a new FileSystem will be created and a new entry will be added to > FileSystem.CACHE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)