[jira] [Updated] (VFS-684) Missing thread-safety information in API documentation
[
https://issues.apache.org/jira/browse/VFS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryl Odnert updated VFS-684:
-
Priority: Minor (was: Major)
> Missing thread-safety information in API documentation
> --
>
> Key: VFS-684
> URL: https://issues.apache.org/jira/browse/VFS-684
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Minor
> Labels: documentation
>
> The API documentation for VFS is missing advisory information about the
> safety (or danger) of sharing class instances across multiple threads. Refer
> to bugs VFS-253 and VFS-683 for examples of what can happen when the same
> {{FileObject}} instance is accessed in more than one thread. However, there
> is caching that's happening in
> {{org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile}}. [Source
> code is
> here|https://svn.apache.org/viewvc/commons/proper/vfs/tags/commons-vfs2-project-2.2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/AbstractFileSystem.java?revision=1811361=markup#l303].
> This will definitely result in the same {{FileObject}} being referenced from
> distinct threads if both threads call {{resolveFile}} on the same instance of
> a {{FileSystem}} that extends {{AbstractFileSystem}}. So, it's unclear where
> applications that use VFS are required to apply synchronization and/or
> whether each thread is required to use a distinct {{FileSystem}} instance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (VFS-253) AbstractFileObject: wrong synchronization of content-related code
[
https://issues.apache.org/jira/browse/VFS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699609#comment-16699609
]
Daryl Odnert edited comment on VFS-253 at 11/26/18 9:41 PM:
I opened a new bug today - VFS-684 - requesting that the API documentation is
fixed to identify requirements for multi-threaded applications.
was (Author: daryl.odnert):
I opened a new bug today requesting that the API documentation is fixed to
identify requirements for multi-threaded applications.
> AbstractFileObject: wrong synchronization of content-related code
> -
>
> Key: VFS-253
> URL: https://issues.apache.org/jira/browse/VFS-253
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Marek Zawirski
>Priority: Major
>
> Creating content through {{AbstractFileObject#getContent()}} and
> {{DefaultFileContent}} itself seem to be synchronized, but closing the
> content by {{AbstractFileObject#close()}} and checking whether it is open, by
> {{AbstractFileObject#isContentOpen()}} are NOT synchronized.
> Both these methods miss some lock-object. For {{close()}} it may result in
> severe race condition in case of {{FileObject}} shared across more than one
> thread.
> BTW, thead-safeness of important VFS classes/interfaces like {{FileObject}}
> is not documented in javadoc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-253) AbstractFileObject: wrong synchronization of content-related code
[
https://issues.apache.org/jira/browse/VFS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699609#comment-16699609
]
Daryl Odnert commented on VFS-253:
--
I opened a new bug today requesting that the API documentation is fixed to
identify requirements for multi-threaded applications.
> AbstractFileObject: wrong synchronization of content-related code
> -
>
> Key: VFS-253
> URL: https://issues.apache.org/jira/browse/VFS-253
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Marek Zawirski
>Priority: Major
>
> Creating content through {{AbstractFileObject#getContent()}} and
> {{DefaultFileContent}} itself seem to be synchronized, but closing the
> content by {{AbstractFileObject#close()}} and checking whether it is open, by
> {{AbstractFileObject#isContentOpen()}} are NOT synchronized.
> Both these methods miss some lock-object. For {{close()}} it may result in
> severe race condition in case of {{FileObject}} shared across more than one
> thread.
> BTW, thead-safeness of important VFS classes/interfaces like {{FileObject}}
> is not documented in javadoc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-684) Missing thread-safety information in API documentation
[
https://issues.apache.org/jira/browse/VFS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryl Odnert updated VFS-684:
-
Affects Version/s: 2.2
Labels: documentation (was: )
Description: The API documentation for VFS is missing advisory
information about the safety (or danger) of sharing class instances across
multiple threads. Refer to bugs VFS-253 and VFS-683 for examples of what can
happen when the same {{FileObject}} instance is accessed in more than one
thread.
> Missing thread-safety information in API documentation
> --
>
> Key: VFS-684
> URL: https://issues.apache.org/jira/browse/VFS-684
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Labels: documentation
>
> The API documentation for VFS is missing advisory information about the
> safety (or danger) of sharing class instances across multiple threads. Refer
> to bugs VFS-253 and VFS-683 for examples of what can happen when the same
> {{FileObject}} instance is accessed in more than one thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-684) Missing thread-safety information in API documentation
[
https://issues.apache.org/jira/browse/VFS-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryl Odnert updated VFS-684:
-
Description: The API documentation for VFS is missing advisory information
about the safety (or danger) of sharing class instances across multiple
threads. Refer to bugs VFS-253 and VFS-683 for examples of what can happen when
the same {{FileObject}} instance is accessed in more than one thread. However,
there is caching that's happening in
{{org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile}}. [Source
code is
here|https://svn.apache.org/viewvc/commons/proper/vfs/tags/commons-vfs2-project-2.2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/AbstractFileSystem.java?revision=1811361=markup#l303].
This will definitely result in the same {{FileObject}} being referenced from
distinct threads if both threads call {{resolveFile}} on the same instance of a
{{FileSystem}} that extends {{AbstractFileSystem}}. So, it's unclear where
applications that use VFS are required to apply synchronization and/or whether
each thread is required to use a distinct {{FileSystem}} instance. (was: The
API documentation for VFS is missing advisory information about the safety (or
danger) of sharing class instances across multiple threads. Refer to bugs
VFS-253 and VFS-683 for examples of what can happen when the same
{{FileObject}} instance is accessed in more than one thread.)
> Missing thread-safety information in API documentation
> --
>
> Key: VFS-684
> URL: https://issues.apache.org/jira/browse/VFS-684
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Labels: documentation
>
> The API documentation for VFS is missing advisory information about the
> safety (or danger) of sharing class instances across multiple threads. Refer
> to bugs VFS-253 and VFS-683 for examples of what can happen when the same
> {{FileObject}} instance is accessed in more than one thread. However, there
> is caching that's happening in
> {{org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile}}. [Source
> code is
> here|https://svn.apache.org/viewvc/commons/proper/vfs/tags/commons-vfs2-project-2.2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/AbstractFileSystem.java?revision=1811361=markup#l303].
> This will definitely result in the same {{FileObject}} being referenced from
> distinct threads if both threads call {{resolveFile}} on the same instance of
> a {{FileSystem}} that extends {{AbstractFileSystem}}. So, it's unclear where
> applications that use VFS are required to apply synchronization and/or
> whether each thread is required to use a distinct {{FileSystem}} instance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699602#comment-16699602
]
Daryl Odnert commented on VFS-683:
--
I have logged VFS-684 requesting that the documentation should be fixed. I'm
reluctant to start a discussion on the mailing list about the issue as I'm not
currently a subscriber and don't want to subscribe just for the purpose of
raising this issue. If you think it's the right thing to do, we can close this
issue as a duplicate of VFS-684.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-684) Missing thread-safety information in API documentation
Daryl Odnert created VFS-684: Summary: Missing thread-safety information in API documentation Key: VFS-684 URL: https://issues.apache.org/jira/browse/VFS-684 Project: Commons VFS Issue Type: Bug Reporter: Daryl Odnert -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699478#comment-16699478
]
Daryl Odnert commented on VFS-683:
--
[~ottobackwards] - Yes, I know there are a number of different approaches to
work around the problem. I logged this bug report as a request to either fix
the software (if there is agreement that there is a defect) or fix the
documentation if my multi-threaded application is using VFS incorrectly.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Assignee: Otto Fowler
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryl Odnert updated VFS-683:
-
Attachment: Main.java
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695425#comment-16695425
]
Daryl Odnert commented on VFS-683:
--
Here is a Java program that demonstrates a problem where if you have more than
one thread attempting to read the contents of the children of the same archive
file, you will get exceptions thrown. The exceptions this applications receives
from VFS are not identical to the {{NullPointerException}} that is listed in
the original problem description, but I think this does demonstrate that there
is either a thread-safety issue that needs to be fixed, or some documentation
that needs to be clarified.
[^Main.java]
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
> Attachments: Main.java
>
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695032#comment-16695032
]
Daryl Odnert commented on VFS-683:
--
All of your comments are consistent with my concern that the caching mechanism
in {{AbstractFileSystem.resolveFile}} is returning the same {{FileObject}}
instance to two different threads, which is apparently a dangerous thing to do.
I'll try to put together a small sample application that reproduces the problem
soon.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694097#comment-16694097
]
Daryl Odnert commented on VFS-683:
--
[~ottobackwards] - In general, are {{FileObject}} instances supposed to be
thread-safe? The documentation is unclear about this.
My colleague and I are suspicious of the caching that's happening in
{{org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile}}. [Source
code is
here|https://svn.apache.org/viewvc/commons/proper/vfs/tags/commons-vfs2-project-2.2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/AbstractFileSystem.java?revision=1811361=markup#l303].
With caching happening here, the same {{FileObject}} instance could be
returned to multiple threads, which would lead to a problem if more than one of
those threads try to read the contents simultaneously.
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in the implementation.
> {noformat}
> 43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
> org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
> java.lang.NullPointerException: Inflater has been closed
> java.lang.NullPointerException: Inflater has been closed
> at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
> at java.util.zip.Inflater.inflate(Inflater.java:257)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at
> org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
> at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
> at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
> at
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> at
> com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryl Odnert updated VFS-683:
-
Description:
In my application, I have two instances of the {{VFSClassLoader}}, each of
which was being used in a distinct thread. Both {{VFSClassLoader}} instances
refer to the same compressed file resource described by a {{FileObject}} that
is passed to the class loader's constructor. Intermittently, the application
throws an exception with the stack trace shown below. So, there seems to be
either a race condition in the code or an undocumented assumption here. If it
is unsupported for two {{VFSClassLoader}} instances to refer to the same
resource (file), then that assumption should be documented. But if that is not
the case, then there is a race condition bug in the implementation.
{noformat}
43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
java.lang.NullPointerException: Inflater has been closed
java.lang.NullPointerException: Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
at java.util.zip.Inflater.inflate(Inflater.java:257)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at
org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
at
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
at
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
at
com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
{noformat}
was:
In my application, I had two instances of the {{VFSClassLoader}}, each of which
was being used in a distinct thread. Both {{VFSClassLoader}} instances refer to
the same compressed file resource described by a {{FileObject}} that is passed
to the class loader's constructor. Intermittently, the application throws an
exception with the stack trace shown below. So, there seems to be either a race
condition in the code or an undocumented assumption here. If it is unsupported
for two {{VFSClassLoader}} instances to refer to the same resource (file), then
that assumption should be documented. But if that is not the case, then there
is a race condition bug in the implementation.
{noformat}
43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
java.lang.NullPointerException: Inflater has been closed
java.lang.NullPointerException: Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
at java.util.zip.Inflater.inflate(Inflater.java:257)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at
org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
at
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
at
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
at
com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
{noformat}
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which was being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in
[jira] [Updated] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
[
https://issues.apache.org/jira/browse/VFS-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daryl Odnert updated VFS-683:
-
Description:
In my application, I have two instances of the {{VFSClassLoader}}, each of
which is being used in a distinct thread. Both {{VFSClassLoader}} instances
refer to the same compressed file resource described by a {{FileObject}} that
is passed to the class loader's constructor. Intermittently, the application
throws an exception with the stack trace shown below. So, there seems to be
either a race condition in the code or an undocumented assumption here. If it
is unsupported for two {{VFSClassLoader}} instances to refer to the same
resource (file), then that assumption should be documented. But if that is not
the case, then there is a race condition bug in the implementation.
{noformat}
43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
java.lang.NullPointerException: Inflater has been closed
java.lang.NullPointerException: Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
at java.util.zip.Inflater.inflate(Inflater.java:257)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at
org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
at
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
at
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
at
com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
{noformat}
was:
In my application, I have two instances of the {{VFSClassLoader}}, each of
which was being used in a distinct thread. Both {{VFSClassLoader}} instances
refer to the same compressed file resource described by a {{FileObject}} that
is passed to the class loader's constructor. Intermittently, the application
throws an exception with the stack trace shown below. So, there seems to be
either a race condition in the code or an undocumented assumption here. If it
is unsupported for two {{VFSClassLoader}} instances to refer to the same
resource (file), then that assumption should be documented. But if that is not
the case, then there is a race condition bug in the implementation.
{noformat}
43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
java.lang.NullPointerException: Inflater has been closed
java.lang.NullPointerException: Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
at java.util.zip.Inflater.inflate(Inflater.java:257)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at
org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
at
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
at
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
at
com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
{noformat}
> Thread safety issue in VFSClassLoader - NullPointerException thrown
> ---
>
> Key: VFS-683
> URL: https://issues.apache.org/jira/browse/VFS-683
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Daryl Odnert
>Priority: Major
>
> In my application, I have two instances of the {{VFSClassLoader}}, each of
> which is being used in a distinct thread. Both {{VFSClassLoader}} instances
> refer to the same compressed file resource described by a {{FileObject}} that
> is passed to the class loader's constructor. Intermittently, the application
> throws an exception with the stack trace shown below. So, there seems to be
> either a race condition in the code or an undocumented assumption here. If it
> is unsupported for two {{VFSClassLoader}} instances to refer to the same
> resource (file), then that assumption should be documented. But if that is
> not the case, then there is a race condition bug in
[jira] [Created] (VFS-683) Thread safety issue in VFSClassLoader - NullPointerException thrown
Daryl Odnert created VFS-683:
Summary: Thread safety issue in VFSClassLoader -
NullPointerException thrown
Key: VFS-683
URL: https://issues.apache.org/jira/browse/VFS-683
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.2
Reporter: Daryl Odnert
In my application, I had two instances of the {{VFSClassLoader}}, each of which
was being used in a distinct thread. Both {{VFSClassLoader}} instances refer to
the same compressed file resource described by a {{FileObject}} that is passed
to the class loader's constructor. Intermittently, the application throws an
exception with the stack trace shown below. So, there seems to be either a race
condition in the code or an undocumented assumption here. If it is unsupported
for two {{VFSClassLoader}} instances to refer to the same resource (file), then
that assumption should be documented. But if that is not the case, then there
is a race condition bug in the implementation.
{noformat}
43789 WARN {} c.a.e.u.PreferredPathClassLoader - While loading class
org.apache.hive.jdbc.HiveDatabaseMetaData, rethrowing unexpected
java.lang.NullPointerException: Inflater has been closed
java.lang.NullPointerException: Inflater has been closed
at java.util.zip.Inflater.ensureOpen(Inflater.java:389)
at java.util.zip.Inflater.inflate(Inflater.java:257)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:152)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at
org.apache.commons.vfs2.util.MonitorInputStream.read(MonitorInputStream.java:91)
at org.apache.commons.vfs2.FileUtil.getContent(FileUtil.java:47)
at org.apache.commons.vfs2.impl.Resource.getBytes(Resource.java:102)
at
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:179)
at
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
at
com.atscale.engine.utils.PreferredPathClassLoader.findClass(PreferredPathClassLoader.scala:54)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
