Hi!
Hmmm … I tried to reproduce it like this:
FileObject fos =
VFS.getManager().resolveFile("ftp://XYZ.com/public/ test with space", fops);
fos.getType();
fos.getChildren();
fos.refresh();
fos.getType();
fos.getChildren();
After the refresh() I just get one ftp list … can you please outline with
code how to reproduce the problem.
Thanks!
Ciao,
Mario
Von: Kirill Safonov [mailto:kirill.safo...@gmail.com]
Gesendet: Mittwoch, 12. Mai 2010 17:07
An: 'Commons Users List'
Cc: Mario Ivankovits
Betreff: potential problem: FtpFileObject caches children when not attached
Hello,
While digging a bit into FTP performance, I’ve noticed the following:
When FtpFileObject.refresh() is called, FtpFileObject.children field is
reset to null in FtpFileObject.doDetach(), and AbstractFileObject.attached
flag is set to false (this is OK)
But, if then FtpFileObject.getChildFile() is called (this may happen when
getType() is invoked for one of the child files – see below), current
implementation will ignore ‘attached’ state and silently fill children cache
by calling doGetChildren().
The result is that FtpFileObject remains in inconsistent state: it is not
attached with AbstractFileObject.type field = null, child names cache
(AbstractFileObject.children) = null, but has children cache bulit.
I’m not currently sure which consequences it may cause.
What I’ve found up to date is that when I load list of children I see that
two FTP LIST commands are issued:
- first one is to list the children themselves
- then parent file is refreshed since CacheStrategy is ON_RESOLVE
(this is actually another issue I’d like to discuss, since it gives a
performance drop clearing the children cache right after is was build)
- and then another LIST call that comes from child.getType(). If
there was no inconsistency I described above, this LIST would have been
called for each of the children.
Hope all this makes sense,
Regards,
Kirill
smime.p7s
Description: S/MIME cryptographic signature
