hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10987) Provide an iterator-based listing API for FileSystem
Date Thu, 30 Oct 2014 22:07:34 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-10987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190930#comment-14190930
] 

Colin Patrick McCabe commented on HADOOP-10987:
-----------------------------------------------

Thanks for working on this!

{code}
1703	  /**
1704	   * Returns a remote iterator so that followup calls are made on demand
1705	   * while consuming the entries. This reduces memory consumption during
1706	   * listing of a large directory.
1707	   *
1708	   * @param p target path
1709	   * @return remote iterator
1710	   */
1711	  public RemoteIterator<FileStatus> listStatusIterator(final Path p)
{code}

This JavaDoc seems misleading because it implies that the function below "reduces memory consumption."
 But actually that function {{FileSystem#listStatusIterator}} uses just as much memory as
{{listStatus}} (since it just calls listStatus).  The memory consumption is only reduced if
the subclass overrides this method with a more efficient implementation.

What happened to this comment from the earlier version?
{code}
    // Each file system implementation should override this method and 
    // provide more efficient implementation, if possible.
{code}

It seems like that belongs in the JavaDoc for this function.

{code}
777	      @Override
778	      public RemoteIterator<LocatedFileStatus> next(final FileSystem fs, final Path
p)
779	          throws IOException {
780	        if (fs instanceof DistributedFileSystem) {
781	          return ((DistributedFileSystem)fs).listLocatedStatus(p, filter);
785	        }	782	        }
783	        // symlink resolution for this methos does not work cross file systems
784	        // because it is a protected method.
785	        throw new IOException("Link resolution does not work with multiple " +
786	            "file systems for listLocatedStatus(): " + p);
787	      }
788	    }.resolve(this, absF);
789	  }
{code}
As I commented above, it's not OK to break cross-filesystem symlinks.  What I was suggesting
is not changing {{DistributedFileSystem#listLocatedStatus}} at all.  We don't need to change
this function to introduce the {{listStatusIterator}} function.

> Provide an iterator-based listing API for FileSystem
> ----------------------------------------------------
>
>                 Key: HADOOP-10987
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10987
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>         Attachments: HADOOP-10987.patch, HADOOP-10987.v2.patch, HADOOP-10987.v3.patch,
HADOOP-10987.v4.branch-2.patch, HADOOP-10987.v4.patch
>
>
> Iterator based listing methods already exist in {{FileContext}} for both simple listing
and listing with locations. However, {{FileSystem}} lacks the former.  From what I understand,
it wasn't added to {{FileSystem}} because it was believed to be phased out soon. Since {{FileSystem}}
is very well alive today and new features are getting added frequently, I propose adding an
iterator based {{listStatus}} method. As for the name of the new method, we can use the same
name used in {{FileContext}} : {{listStatusIterator()}}.
> It will be particularly useful when listing giant directories. Without this, the client
has to build up a huge data structure and hold it in memory. We've seen client JVMs running
out of memory because of this.
> Once this change is made, we can modify FsShell, etc. in followup jiras.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message