[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283917#comment-14283917 ] L commented on VFS-558: --- Re: Thanks for testing! I really hope to release soon (so you better not find new bugs ) Sorry: VFS-559 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282877#comment-14282877 ] Bernd Eckenfels commented on VFS-558: - Thanks for testing! I really hope to release soon (so you better not find new bugs :)) Would you mind moving the discussion to us...@common.apache.org mailing list? It would be interesting if you can summarize your tests. If ON_CALL is faster than ON_RESOLVE (which is the default I hope :) I would expect there are some strange timeout issues. If you can have a look at the FTP server command logfile it would be interesting to compare the number and types of commands used in both cases. (and just a reminder the CacheStrategy is only dealing with directory content and file metadata, so if you mostly transfer file content it is not much of a change). 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281876#comment-14281876 ] Bernd Eckenfels commented on VFS-558: - Thanks for the report, I agree with your analysis, we need to check that. BTW: I also think that the case of moving a file into an empty folder must be in the provider test suite. If you have some time, it would be best when you can start with exactly that reproducer. BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. 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 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281955#comment-14281955 ] Bernd Eckenfels commented on VFS-558: - 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. 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 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281944#comment-14281944 ] L commented on VFS-558: --- Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive 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 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281943#comment-14281943 ] L commented on VFS-558: --- Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive 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 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281942#comment-14281942 ] L commented on VFS-558: --- Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive 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 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)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281954#comment-14281954 ] Bernd Eckenfels commented on VFS-558: - Hm, what version of VFS you are using? 2.0 has only 1855 lines in AbstractFileObject and 2.1 (trunk) does not align with the line numbers. Do you maybe have an older trunk version? Can you try a newer trunk version? 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 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)
