Thanks Harsh and Daryn ! Daryn, I tried the option you suggested and changed getFileSystem(String user) implementation as following...
private static FileSystem getFileSystem(String user) throws Exception { final Configuration conf = new Configuration(); conf.set("fs.default.name", "file:///"); UserGroupInformation ugi = UserGroupInformation.createRemoteUser(user); return ugi.doAs(new PrivilegedAction<FileSystem>() { @Override public FileSystem run() { try { return FileSystem.get(new URI("file:///"),conf); } catch(Exception ex) { ex.printStackTrace(); return null; } } }); } but with this implementation also multiple FileSystem instances are created. Did I miss something? As per as my usecase is concerned, we are developing a oozie like application where clients can give a workflow and their hadoop user and also store data on hdfs through us. We are using FileSystem.get(..) api to get handle to FileSystem impl specific to the client's hadoop user. Thanks ----- Original Message ----- From: Daryn Sharp <da...@yahoo-inc.com> To: "user@hadoop.apache.org" <user@hadoop.apache.org> Cc: Himanshu Gupta <para_...@yahoo.com> Sent: Tuesday, 11 September 2012 12:49 AM Subject: Re: FileSystem.get(Uri,Configuration,String) caching issue Yes, the sample code demonstrates what happens when you use a new UGI for every FileSystem.get. If possible you should avoid the variant of fs.get that accepts the user as a string since it may create another UGI from the string user on every call. The cache will fill with instances for every new UGI. If you need a filesystem for your kerberos or unix user, don't bother with passing the user or manipulating the UGI since the default for fs.get uses the current user ugi. If you are trying to be another user, use UGI.createRemoteUser and use it to execute your code within a doAs block. All the fs gets will return the same cached object as long as you don't pass in the user string. Normally only daemons that accept requests for arbitrary users have to deal with the ugi. If this is simple app code then I'd suggest leaving the ugi alone. If you have a complex use case, please describe it to us so better advice can be offered. I hope this helps! Daryn On Sep 10, 2012, at 10:14 AM, Harsh J wrote: > What you're seeing is genuine. > > You seem to be hitting the abuse scenario described by Daryn here: > https://issues.apache.org/jira/browse/HDFS-3545?focusedCommentId=13398502&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13398502 > > You can instead choose to skip passing a username for local FS > instances, as I think they don't make much sense when done locally - > as a workaround. > > On Mon, Sep 10, 2012 at 4:59 PM, Himanshu Gupta <para_...@yahoo.com> wrote: >> I am using FileSystem.get(URI uri, Configuration conf, String user) to >> create FileSystem implementation(LocalFileSystem in this case) instances. >> From what I know, FileSystem internally has a cache to retain the objects >> based on uri and user. So if I call FileSystem.get(..) method multiple times >> with same uri and user, then only one instance of LocalFileSystem needs to >> be created and cached. However, I observed(with hadoop-core-1.0.0) that each >> call creates a new instance of LocalFileSystem and puts it in the cache >> leading to memory issues. >> >> Please see the code below and let me know if I am doing something wrong. >> >> Thanks >> >> >> import java.net.URI; >> >> import org.apache.hadoop.conf.Configuration; >> import org.apache.hadoop.fs.FileSystem; >> >> public class FileSystemCacheIssue { >> >> private static FileSystem getFileSystem(String user) throws Exception { >> Configuration conf = new Configuration(); >> conf.set("fs.default.name", "file:///"); >> return FileSystem.get(new URI("file:///"),conf,user); >> } >> >> public static void main(String[] args) throws Exception { >> for(int i = 0; i < 1000; i++) { >> getFileSystem("himanshg"); >> } >> >> FileSystem fs = getFileSystem("himanshg"); >> System.out.println(fs.getClass().getCanonicalName()); >> >> //put a breakpoint here and look at the heap dump for number of >> LocalFileSystem >> //instances, Ideally I expect it to be 1, but there are 1001 >> System.out.println("Keep your debugger here and check."); >> } >> } > > > > -- > Harsh J