[
https://issues.apache.org/jira/browse/VFS-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved VFS-114.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.1
Good catch.
Applied.
Thanks!
Ciao,
Mario
> FtpFileObject lists children excessively using ON_RESOLVE cache strategy
> ------------------------------------------------------------------------
>
> Key: VFS-114
> URL: https://issues.apache.org/jira/browse/VFS-114
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.1
> Environment: Mac OS X 10.4.8, Darwin 8.8.0; Java 1.5.0_06;
> Libraries: ant-1.6.2.jar, commons-net-1.4.1.jar, commons-logging-1.0.4.jar,
> commons-collections-3.1.jar, jcifs-0.8.3.jar,
> jakarta-slide-webdavlib-20050629.161100.jar, jdom-1.0.jar,
> commons-httpclient-2.0.2.jar, jsch-0.1.23.jar, xml-apis-1.0.b2.jar,
> oro-2.0.8.jar, maven-xdoc-plugin-1.9.2.jar,
> Reporter: K. Lo Shih
> Priority: Minor
> Fix For: 1.1
>
> Attachments: VFS-114.patch
>
>
> When calling FileObject.getChildren() on a
> org.apache.commons.vfs.provider.ftp.FtpFileObject using the default
> ON_RESOLVE cache strategy, I would FtpClientWrapper.listFiles() to be called
> only once. Instead, because FileObject.refresh() is called once for itself
> and each of its parents for each of the children. For example, if there's a
> file structure like:
> <pre>
> ftp://ftp.example.com
> A/
> B/
> C/
> 1
> 2
> 3
> </pre>
> and you list files for the URL "ftp://ftp.example.com/A/B/C/";. Instead of
> calling listFiles() once on "C", it calls listFiles() on each of "A", "B",
> and "C" for each of the children "1", "2" and "3", i.e. 9 times. I discovered
> this when listing a directory with 709 files--you can imagine my bewilderment
> at how long it took.
> I fixed this by reusing the FtpFileObject.inRefresh flag within
> AbstractFileObject.getChildren() to not refresh the listed directory when its
> children request a refresh. I've used this inRefresh incorrectly, I think. I
> should rather use a separate flag depth counter like
> FtpFileObject.refreshDepth, incremented upon entry into
> AbstractFileObject.getChildren() and decremented upon exit. This approach
> would fix the implementation for providers other than FTP as well. Anyways,
> here's my patch:
> Index:
> core/src/main/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
> ===================================================================
> --- core/src/main/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
> (revision 513805)
> +++ core/src/main/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
> (working copy)
> @@ -94,7 +94,12 @@
> */
> private FTPFile getChildFile(final String name, final boolean flush)
> throws IOException
> {
> - if (flush)
> + /* If we should flush cached children, clear our children map unless
> + * we're in the middle of a refresh in which case we've just recently
> + * refreshed our children. No need to do it again when our children
> are
> + * refresh()ed, calling getChildFile() for themselves from within
> + * getInfo(). See getChildren(). */
> + if (flush && !inRefresh)
> {
> children = null;
> }
> @@ -322,6 +327,28 @@
> return null;
> }
> +
> + /** Returns the file's list of children.
> + *
> + * @return The list of children
> + * @throws FileSystemException If there was a problem listing children
> + * @see AbstratFileObject#getChildren()
> + * @since 1.0
> + */
> + public FileObject[] getChildren() throws FileSystemException {
> + try {
> + /* Wrap our parent implementation, noting that we're refreshing
> so
> + * that we don't refresh() ourselves and each of our parents for
> + * each children. Note that refresh() will list children.
> Meaning,
> + * if if this file has C children, P parents, there will be (C *
> P)
> + * listings made with (C * (P + 1)) refreshes, when there should
> + * really only be 1 listing and C refreshes. */
> + this.inRefresh = true;
> + return super.getChildren();
> + } finally {
> + this.inRefresh = false;
> + }
> + }
> /**
> * Lists the children of the file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
