--- On Fri, 8/21/09, Stefan Bodewig <bode...@apache.org> wrote:
> From: Stefan Bodewig <bode...@apache.org> > Subject: Scanning Resource Collections Several Times > To: dev@ant.apache.org > Date: Friday, August 21, 2009, 3:20 AM > Hi, > > I just closed a bug > <https://issues.apache.org/bugzilla/show_bug.cgi?id=43574> > in delete > that really points to a deeper problem. > > Delete was scanning the same fileset three times. > Once by innocently > calling getDirectoryScanner (and discarding the results if > includeEmptyDirs and removeNotFollowedSymlinks was false), > once by > calling isFileSystemOnly on Resources and once when > iterating. > > If the fileset contained a modified selector, things > couldn't work since > files that had been modified on the first pass wouldn't be > modified on > subsequent passes. > > While I fixed it for filesets now (by caching the result of > the first > scan) it still remains for other resource collections > (which might use > modified as a resource selector) and it may very well > happen in other > tasks as well. > > One culprit is Resources which will create a new > MyCollection in > isFileSystemOnly which again invokes size() on all nested > resource > collections, scanning them before any iteration is > required. Most other > resource collections extend BaseResourceCollection which > has a cache > attribute that is true by default and should avoid the > problem. > > I'd like to modify Resources to > > (1) lazily initialize size() - Delete never > asks for it, for > example. Sounds good. > > (2) Cache the remaining iteration results > when initializing size > The only thing that concerns me about this is the fact that I did make 'cache' an attribute on BaseRC because I thought there might be times caching was not wanted. How would one defeat caching of <resources>? Thanks for all your work of late while the rest of us do other stuff, Stefan! -Matt > Does anybody see a problem with this? > > There probably are more cases where resource collections > could be > scanned multiple times but I'm not sure a complete audit is > warranted. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
