[
https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282815#comment-14282815
]
L commented on VFS-558:
-----------------------
Re: Anyway, I fixed the rename in trunk, can you try?
Yes, it is fixed, thanks.
Re: I would use ON_RESOLVE or even MANUAL and then use refresh() in those
particular places where you want to have an up-to-date view of the children.
Because with ON_CALL you cannot control which of the methods actually need the
refresh and which not. But: this should not be related to your bug report, I
just noticed it.
Since I was getting problems even with ON_CALL, I have added refresh() before
checking if a file exists, and it looks like it has solved spurious warnings. I
cannot be 100% sure because the warnings did not always occur when I have run
my tests without refresh().
Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP
quite slow.
Re: and really consider not using ON_CALL
This sounds intuitively as a correct piece of advice.
The thing is: my tests show different results:
I have a code that initializes an instance of StandardFileSystemManager with a
setCacheStrategy(CacheStrategy.ON_CALL) before .init().
My tests accessing a local FS with setCacheStrategy(CacheStrategy.ON_CALL)
commented out are about 40% faster than with
setCacheStrategy(CacheStrategy.ON_CALL) performed. As expected.
But FTP tests with ON_CALL are about the same 40% faster than with
setCacheStrategy(CacheStrategy.ON_CALL) commented out. Dare to explain?
> java.lang.UnsupportedOperationException in FtpFileObject
> --------------------------------------------------------
>
> Key: VFS-558
> URL: https://issues.apache.org/jira/browse/VFS-558
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: L
> Assignee: Bernd Eckenfels
> Fix For: 2.1
>
>
> I am getting the following exception in my code:
> java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866)
> at
> org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241)
> at
> org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184)
> ...
> I guess it is caused by the fact that children field is set to
> EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked.
> I also do not like line 1866 in AbstractFileObject.java. To me it looks like
> it might be the real cause of the problem:
> FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType());
> Must it not be destFile.getType()?
> But even if I am right about AbstractFileObject.java:1866,
> FtpFileObject.onChildrenChanged() must be corrected as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
