[jira] [Commented] (VFS-833) org.apache.commons.vfs2.FileSystemOptions#options is not synchronized

["Bernd Eckenfels (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/VFS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703793#comment-17703793 ] 

Bernd Eckenfels commented on VFS-833:
-------------------------------------

Thanks for the report. Can you give an example when this actually happens - I.e. who changes why fs options. This does not really work very well since they are part of the Idendity of a filesystem instance. So I would say most of the time they have to be immutable. At least this is what VFS assumes why it does not synchronize. Maybe it’s enough if we do a defensive copy?

> org.apache.commons.vfs2.FileSystemOptions#options is not synchronized
> ---------------------------------------------------------------------
>
>                 Key: VFS-833
>                 URL: https://issues.apache.org/jira/browse/VFS-833
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.9.0
>            Reporter: Kannan Ramamoorthy
>            Priority: Major
>
> *Problem:*
> The map `org.apache.commons.vfs2.FileSystemOptions#options` is TreeMap. The datastructure is  not thread-safe and resulting in situations like [this|https://ivoanjo.me/blog/2018/07/21/writing-to-a-java-treemap-concurrently-can-lead-to-an-infinite-loop-during-reads/]  when used in multithreaded environments.
> *Workaround:*
> As a workaround, we have to synchronize the `FileSystemOptions` in all the places of the code. 
> *Solution:*
>  *  If there is no issue, the constructor `
> protected FileSystemOptions(Map<FileSystemOptionKey, Object> options)` can be made public, so that users will have an option to pass a synchronized map when they have to. * Or, wrap the `TreeMap` instance with `java.util.Collections#synchronizedMap`, ensuring thread safety at the core.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)