[
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)
