[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPools
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694308#comment-16694308
]
ASF GitHub Bot commented on POOL-359:
-
Github user grimreaper commented on the issue:
https://github.com/apache/commons-pool/pull/17
The new test doesn't fail for me if I reverse the original change:
```
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.apache.commons.pool2.impl.TestGenericObjectPool
[INFO] Tests run: 84, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
106.528 s - in org.apache.commons.pool2.impl.TestGenericObjectPool
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 84, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 01:57 min
[INFO] Finished at: 2018-11-20T22:58:11-08:00
[INFO]
mvn test -Dtest=TestGenericObjectPool 34.10s user 7.66s system 34% cpu
1:59.76 total; max RSS 305800Ki
[45682 22:58:11.583 eax@FlyingEagle ...ache/commons/commons-pool]∴git diff
(git:commons-pool)-[master●]
diff --git i/src/main/java/org/apache/commons/pool2/impl/EvictionTimer.java
w/src/main/java/org/apache/commons/pool2/impl/EvictionTimer.java
index b92b87a9..2fc9ffd8 100644
--- i/src/main/java/org/apache/commons/pool2/impl/EvictionTimer.java
+++ w/src/main/java/org/apache/commons/pool2/impl/EvictionTimer.java
@@ -94,7 +94,7 @@ static synchronized void schedule(
static synchronized void cancel(
final BaseGenericObjectPool.Evictor task, final long
timeout, final TimeUnit unit) {
task.cancel();
-if (executor != null && executor.getQueue().size() == 0) {
+if (executor.getQueue().size() == 0) {
executor.shutdown();
try {
executor.awaitTermination(timeout, unit);
```
> NullPointerException closing multiple GenericObjectPools
>
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPools
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694311#comment-16694311
]
ASF GitHub Bot commented on POOL-359:
-
Github user grimreaper commented on the issue:
https://github.com/apache/commons-pool/pull/17
hrm... or at least its not consistent. I just ran it twice more and failed
only once.
∴mvn test -Dtest=TestGenericObjectPool#testCloseMultiplePools
I'm not generally the biggest fan of tests that don't rely on a fixed
clock: you're guaranteed to eventually get a failure.
> NullPointerException closing multiple GenericObjectPools
>
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-731) Allow user to specify the comments & separator chars
[ https://issues.apache.org/jira/browse/CONFIGURATION-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694292#comment-16694292 ] Shuai Zhang commented on CONFIGURATION-731: --- You are right. I'll fix it & submit new patch a few days later. > Allow user to specify the comments & separator chars > > > Key: CONFIGURATION-731 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-731 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.4 >Reporter: Shuai Zhang >Priority: Major > Attachments: CONFIGURATION-731.001.patch, CONFIGURATION-731.002.patch > > > Currently the INIConfiguration defined comments & separator chars as final > static fields, which made it impossible for the user control the behavior of > INIConfiguration parsing. I suggest making them as default value, open setter > & getter methods for the comment & separator chars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPools
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694283#comment-16694283
]
ASF GitHub Bot commented on POOL-359:
-
Github user mswintermeyer commented on the issue:
https://github.com/apache/commons-pool/pull/17
Also, thank you for merging in the meantime, as well as for contributing
your time to maintain the project!
> NullPointerException closing multiple GenericObjectPools
>
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPools
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694280#comment-16694280
]
ASF GitHub Bot commented on POOL-359:
-
Github user mswintermeyer commented on the issue:
https://github.com/apache/commons-pool/pull/17
@garydgregory the test was failing on my machine without the main code
change, so thanks for flagging that it was not consistent! I've updated the
test, and I believe this time it's a consistent failure :)
> NullPointerException closing multiple GenericObjectPools
>
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
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=16694200#comment-16694200
]
Otto Fowler commented on VFS-683:
-
As to in general... The interface for FileObject is pretty clear that there
should be only one input stream opened for any one file at any one time, at
least that is my take. It would be nice if it where more explicit from a
higher level.
You may want to send something to the commons list with a [VFS] subject.
> 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=16694189#comment-16694189
]
Otto Fowler commented on VFS-683:
-
I can't speak to the intent, I'm not one of the original authors, and have only
worked with the library myself as you probably have in a couple of projects, as
well as trying to fix a couple of bugs. And I am wrong a lot ;)
Further investigation:
If you look at DefaultFileContent, it looks like we create multiple input
streams and store them per thread in thread local. And then they are closed as
such.
BUT: If this is a ZipFileObject: The java util zip library says:
{code:java}
/**
* Returns an input stream for reading the contents of the specified
* zip file entry.
*
* Closing this ZIP file will, in turn, close all input
* streams that have been returned by invocations of this method.
*
* @param entry the zip file entry
* @return the input stream for reading the contents of the specified
* zip file entry.
* @throws ZipException if a ZIP format error has occurred
* @throws IOException if an I/O error has occurred
* @throws IllegalStateException if the zip file has been closed
*/
public InputStream getInputStream(ZipEntry entry) throws IOException {
{code}
Which doesn't seem good.
Still would need to reproduce
> 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] [Comment Edited] (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=16693974#comment-16693974
]
Otto Fowler edited comment on VFS-683 at 11/21/18 1:18 AM:
---
any kind of small sample project that can reproduce the issue would be helpful.
what the provider is, what the file is etc.
was (Author: ottobackwards):
any kind of small sample project that can reproduce the issue would be helpful.
> 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=16693981#comment-16693981
]
Otto Fowler commented on VFS-683:
-
{code:java}
/**
* Returns an input stream for reading the file's content.
*
* There may only be a single input or output stream open for the file at any
time.
*
* @return An input stream to read the file's content from. The input stream is
buffered, so there is no need to
* wrap it in a {@code BufferedInputStream}.
* @throws FileSystemException If the file does not exist, or is being read, or
is being written, or on error
* opening the stream.
*/
InputStream getInputStream() throws FileSystemException;
{code}
Just from looking through things, It doesn't seem correct to have two threads
going through here.
The Resource.getBytes() call explicitly CLOSES the stream. So, it isn't
thread safe for two readers if there is only ever one stream from the same
object
> 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=16693974#comment-16693974
]
Otto Fowler commented on VFS-683:
-
any kind of small sample project that can reproduce the issue would be helpful.
> 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)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693829#comment-16693829
]
Gilles commented on RNG-57:
---
bq. I'll commit the new result files
Done.
We should also update the benchmarks.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-61) PermutationSampler shuffle contains unnecessary conditional
[
https://issues.apache.org/jira/browse/RNG-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved RNG-61.
---
Resolution: Fixed
> PermutationSampler shuffle contains unnecessary conditional
> ---
>
> Key: RNG-61
> URL: https://issues.apache.org/jira/browse/RNG-61
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Reporter: Alex D Herbert
>Priority: Trivial
> Fix For: 1.2
>
>
> The Fisher-Yates algorithm in the PermutationSampler has a conditional {{if}}
> statement within the loop that checks if the step is the first in the loop.
> It then swaps a position with itself. For example for the towards head
> variant:
> {code:java}
> for (int i = 0; i <= start; i++) {
> final int target;
> // Check for start
> if (i == start) {
> target = start; // this means target == i
> } else {
> target = rng.nextInt(start - i + 1) + i;
> }
> // if target == i then this step is not needed.
> final int temp = list[target];
> list[target] = list[i];
> list[i] = temp;
> }
> {code}
> This can be removed by altering the iteration loop:
> {code:java}
> for (int i = start; i > 0; i--) {
> final int target = rng.nextInt(i + 1);
> final int temp = list[target];
> list[target] = list[i];
> list[i] = temp;
> }
> {code}
> An equivalent fix is available for the shuffle towards the tail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RNG-63) Deprecate obsolete methods
Gilles created RNG-63:
-
Summary: Deprecate obsolete methods
Key: RNG-63
URL: https://issues.apache.org/jira/browse/RNG-63
Project: Commons RNG
Issue Type: Task
Components: core
Reporter: Gilles
Fix For: 1.2
RNG-57 made methods from {{NumberFactory}} obsolete:
* {{makeBoolean(int)}}
* {{makeBoolean(long)}}
* {{makeInt(long)}}
Coverage has thus
[decreased|https://coveralls.io/builds/20211017/source?filename=commons-rng-core/src/main/java/org/apache/commons/rng/core/util/NumberFactory.java].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-679) NullPointerException in FtpFileObject.doGetLastModifiedTime()
[
https://issues.apache.org/jira/browse/VFS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-679.
--
Resolution: Fixed
Fix Version/s: 2.3
Committed to svn trunk.
Please try 2.3-SNAPSHOT.
> NullPointerException in FtpFileObject.doGetLastModifiedTime()
> -
>
> Key: VFS-679
> URL: https://issues.apache.org/jira/browse/VFS-679
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds, 2.2
>Reporter: Boris Petrov
>Priority: Blocker
> Fix For: 2.3
>
>
> This is similar to https://issues.apache.org/jira/browse/VFS-294 but it is
> very old so I'm not sure how relevant it is.
> We're getting numerous exceptions like:
> {noformat}
> org.apache.commons.vfs2.FileSystemException: Could not determine the size of
> file "ftp://ftp.pbteu.com/VMRType.reg;.
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:134)
> ...
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetContentSize(FtpFileObject.java:449)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:132)
> ... 13 common frames omitted
> {noformat}
>
> And:
>
> {noformat}
> 10:21:15.427 [Thread-20] ERROR o.a.c.vfs2.impl.DefaultFileMonitor - Could not
> determine the last modified timestamp of "ftp://ftp.pbteu.com/VMRType.reg;.
> org.apache.commons.vfs2.FileSystemException: Could not determine the last
> modified timestamp of "ftp://ftp.pbteu.com/VMRType.reg;.
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getLastModifiedTime(DefaultFileContent.java:156)
> at
> org.apache.commons.vfs2.impl.DefaultFileMonitor$FileMonitorAgent.check(DefaultFileMonitor.java:526)
> at
> org.apache.commons.vfs2.impl.DefaultFileMonitor$FileMonitorAgent.access$200(DefaultFileMonitor.java:367)
> at
> org.apache.commons.vfs2.impl.DefaultFileMonitor.run(DefaultFileMonitor.java:330)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetLastModifiedTime(FtpFileObject.java:469)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getLastModifiedTime(DefaultFileContent.java:154)
> ... 4 common frames omitted
> {noformat}
>
> This is happening on 2.2 and on the current trunk. I'm not sure where to
> start digging from but this is a show-stopper for us. Any help is appreciated!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-294) NullPointerException in FtpFileObject.getChildFile()
[
https://issues.apache.org/jira/browse/VFS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-294.
--
Resolution: Fixed
Fix Version/s: 2.3
Committed to svn trunk.
Please try 2.3-SNAPSHOT.
> NullPointerException in FtpFileObject.getChildFile()
>
>
> Key: VFS-294
> URL: https://issues.apache.org/jira/browse/VFS-294
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Johannes Scharf
>Priority: Major
> Fix For: 2.3
>
>
> During my efforts to find a solution for VFS-293 I've discovered another bug
> regarding threadsafety.
> It seems that FtpFileObject is at least not fully threadsafe. When a
> FtpFileObject is accessed by multiple threads from time to time closing the
> OutputStream for a file fails with a NullPointerException.
> Stacktrace:
> {noformat}
> org.apache.commons.vfs.FileSystemException: Could not close the output
> stream for file
> "ftp://localhost/spring-framework-2.5.5/dist/resources/spring-jms-2.5.xsd;.
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:599)
> at
> at.js.jtransporter.transporter.VFSTransporter$VFSOutputStream.close(VFSTransporter.java:219)
> at at.js.jtransporter.util.Utils.close(Utils.java:40)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.createFile(ResourceWorker.java:108)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.processJob(ResourceWorker.java:52)
> at
> at.js.jtransporter.worker.AbstractRunnableWorker.run(AbstractRunnableWorker.java:82)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: org.apache.commons.vfs.FileSystemException: Could not close the
> output stream for file
> "ftp://localhost/spring-framework-2.5.5/dist/resources/spring-jms-2.5.xsd;.
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.onClose(DefaultFileContent.java:620)
> at
> org.apache.commons.vfs.util.MonitorOutputStream.close(MonitorOutputStream.java:63)
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:595)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:106)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:181)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.onChange(FtpFileObject.java:269)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.endOutput(AbstractFileObject.java:1325)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.endOutput(DefaultFileContent.java:459)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.access$200(DefaultFileContent.java:44)
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.onClose(DefaultFileContent.java:616)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-294) NullPointerException in FtpFileObject.getChildFile()
[
https://issues.apache.org/jira/browse/VFS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-294:
-
Summary: NullPointerException in FtpFileObject.getChildFile() (was:
NullPointerException in FtpFileObject.getChildFile)
> NullPointerException in FtpFileObject.getChildFile()
>
>
> Key: VFS-294
> URL: https://issues.apache.org/jira/browse/VFS-294
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Johannes Scharf
>Priority: Major
>
> During my efforts to find a solution for VFS-293 I've discovered another bug
> regarding threadsafety.
> It seems that FtpFileObject is at least not fully threadsafe. When a
> FtpFileObject is accessed by multiple threads from time to time closing the
> OutputStream for a file fails with a NullPointerException.
> Stacktrace:
> {noformat}
> org.apache.commons.vfs.FileSystemException: Could not close the output
> stream for file
> "ftp://localhost/spring-framework-2.5.5/dist/resources/spring-jms-2.5.xsd;.
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:599)
> at
> at.js.jtransporter.transporter.VFSTransporter$VFSOutputStream.close(VFSTransporter.java:219)
> at at.js.jtransporter.util.Utils.close(Utils.java:40)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.createFile(ResourceWorker.java:108)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.processJob(ResourceWorker.java:52)
> at
> at.js.jtransporter.worker.AbstractRunnableWorker.run(AbstractRunnableWorker.java:82)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: org.apache.commons.vfs.FileSystemException: Could not close the
> output stream for file
> "ftp://localhost/spring-framework-2.5.5/dist/resources/spring-jms-2.5.xsd;.
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.onClose(DefaultFileContent.java:620)
> at
> org.apache.commons.vfs.util.MonitorOutputStream.close(MonitorOutputStream.java:63)
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:595)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:106)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:181)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.onChange(FtpFileObject.java:269)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.endOutput(AbstractFileObject.java:1325)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.endOutput(DefaultFileContent.java:459)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.access$200(DefaultFileContent.java:44)
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.onClose(DefaultFileContent.java:616)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-61) PermutationSampler shuffle contains unnecessary conditional
[
https://issues.apache.org/jira/browse/RNG-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693793#comment-16693793
]
ASF GitHub Bot commented on RNG-61:
---
Github user asfgit closed the pull request at:
https://github.com/apache/commons-rng/pull/13
> PermutationSampler shuffle contains unnecessary conditional
> ---
>
> Key: RNG-61
> URL: https://issues.apache.org/jira/browse/RNG-61
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Reporter: Alex D Herbert
>Priority: Trivial
> Fix For: 1.2
>
>
> The Fisher-Yates algorithm in the PermutationSampler has a conditional {{if}}
> statement within the loop that checks if the step is the first in the loop.
> It then swaps a position with itself. For example for the towards head
> variant:
> {code:java}
> for (int i = 0; i <= start; i++) {
> final int target;
> // Check for start
> if (i == start) {
> target = start; // this means target == i
> } else {
> target = rng.nextInt(start - i + 1) + i;
> }
> // if target == i then this step is not needed.
> final int temp = list[target];
> list[target] = list[i];
> list[i] = temp;
> }
> {code}
> This can be removed by altering the iteration loop:
> {code:java}
> for (int i = start; i > 0; i--) {
> final int target = rng.nextInt(i + 1);
> final int temp = list[target];
> list[target] = list[i];
> list[i] = temp;
> }
> {code}
> An equivalent fix is available for the shuffle towards the tail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693792#comment-16693792
]
ASF GitHub Bot commented on RNG-57:
---
Github user asfgit closed the pull request at:
https://github.com/apache/commons-rng/pull/12
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-731) Allow user to specify the comments & separator chars
[ https://issues.apache.org/jira/browse/CONFIGURATION-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693788#comment-16693788 ] Oliver Heger commented on CONFIGURATION-731: In order to fully integrate the new properties with the builder framework, the parameter interfaces and classes for INIConfiguration should be extended as well. Have a look at the _INIBuilderProperties_ interface and the _INIBuilderParametersImpl_ class in the _builder_ package. > Allow user to specify the comments & separator chars > > > Key: CONFIGURATION-731 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-731 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.4 >Reporter: Shuai Zhang >Priority: Major > Attachments: CONFIGURATION-731.001.patch, CONFIGURATION-731.002.patch > > > Currently the INIConfiguration defined comments & separator chars as final > static fields, which made it impossible for the user control the behavior of > INIConfiguration parsing. I suggest making them as default value, open setter > & getter methods for the comment & separator chars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693722#comment-16693722
]
Gilles commented on RNG-57:
---
bq. WELL_1024_A is wrong for BigCrush (the user guide states 4,6,5)
Typo indeed.
bq. WELL_1024_A and WELL_44497B are wrong for Dieharder as the diehard_sums
test failure is not ignored
The table shows all failures, to be consistent with the output from the
software; the note indicates that "diehard_sums" may not be trusted (as per the
note on the software's web site), not that it is not counted.
bq. The changes to use cached values slightly increase the number of failures
How do you draw that conclusion?
I'd think that some of the results are different because the seed/sequences are
different.
I'll commit the new result files (for all RNGs).
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #384: Travis: Stop building with Java 9 and 10, as these ...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/384 [](https://coveralls.io/builds/20206792) Coverage remained the same at 95.233% when pulling **c035de97504a9ba721e5617584e08f1b1f66d455 on PascalSchumacher:travis_drop_java9_and_10** into **5cdac9cfd5a74b0a52ebde32798b973c6edbaa79 on apache:master**. ---
[GitHub] commons-lang pull request #384: Travis: Stop building with Java 9 and 10, as...
GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-lang/pull/384 Travis: Stop building with Java 9 and 10, as these are superseded by ⦠â¦Java 11 and not supported anymore. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-lang travis_drop_java9_and_10 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/384.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #384 commit c035de97504a9ba721e5617584e08f1b1f66d455 Author: pascalschumacher Date: 2018-11-20T17:42:57Z Travis: Stop building with Java 9 and 10, as these are superseded by Java 11 and not supported anymore. ---
[GitHub] commons-lang pull request #383: Make whitespace use consistent and add check...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/383 ---
[jira] [Closed] (VFS-682) Throw a org.apache.commons.vfs2.FileSystemException instead of a NullPointerException in org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(FileName, String, N
[
https://issues.apache.org/jira/browse/VFS-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-682.
Resolution: Fixed
in svn trunk.
> Throw a org.apache.commons.vfs2.FileSystemException instead of a
> NullPointerException in
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(FileName,
> String, NameScope)
> ---
>
> Key: VFS-682
> URL: https://issues.apache.org/jira/browse/VFS-682
> Project: Commons VFS
> Issue Type: Improvement
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Throw a {{org.apache.commons.vfs2.FileSystemException}} instead of a
> {{NullPointerException}} in
> {{org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(FileName,
> String, NameScope)}}
> Since we already throw a {{org.apache.commons.vfs2.FileSystemException}} when
> {{base}} is {{null}}, we should also throw the same exception when {{name}}
> is null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-682) Throw a org.apache.commons.vfs2.FileSystemException instead of a NullPointerException in org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(FileName, String,
Gary Gregory created VFS-682:
Summary: Throw a org.apache.commons.vfs2.FileSystemException
instead of a NullPointerException in
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(FileName,
String, NameScope)
Key: VFS-682
URL: https://issues.apache.org/jira/browse/VFS-682
Project: Commons VFS
Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.3
Throw a {{org.apache.commons.vfs2.FileSystemException}} instead of a
{{NullPointerException}} in
{{org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(FileName,
String, NameScope)}}
Since we already throw a {{org.apache.commons.vfs2.FileSystemException}} when
{{base}} is {{null}}, we should also throw the same exception when {{name}} is
null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-294) NullPointerException in FtpFileObject.getChildFile
[
https://issues.apache.org/jira/browse/VFS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-294:
-
Summary: NullPointerException in FtpFileObject.getChildFile (was:
FtpFileObject is not threadsafe)
> NullPointerException in FtpFileObject.getChildFile
> --
>
> Key: VFS-294
> URL: https://issues.apache.org/jira/browse/VFS-294
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Johannes Scharf
>Priority: Major
>
> During my efforts to find a solution for VFS-293 I've discovered another bug
> regarding threadsafety.
> It seems that FtpFileObject is at least not fully threadsafe. When a
> FtpFileObject is accessed by multiple threads from time to time closing the
> OutputStream for a file fails with a NullPointerException.
> Stacktrace:
> {noformat}
> org.apache.commons.vfs.FileSystemException: Could not close the output
> stream for file
> "ftp://localhost/spring-framework-2.5.5/dist/resources/spring-jms-2.5.xsd;.
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:599)
> at
> at.js.jtransporter.transporter.VFSTransporter$VFSOutputStream.close(VFSTransporter.java:219)
> at at.js.jtransporter.util.Utils.close(Utils.java:40)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.createFile(ResourceWorker.java:108)
> at
> at.js.jtransporter.worker.resource.ResourceWorker.processJob(ResourceWorker.java:52)
> at
> at.js.jtransporter.worker.AbstractRunnableWorker.run(AbstractRunnableWorker.java:82)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: org.apache.commons.vfs.FileSystemException: Could not close the
> output stream for file
> "ftp://localhost/spring-framework-2.5.5/dist/resources/spring-jms-2.5.xsd;.
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.onClose(DefaultFileContent.java:620)
> at
> org.apache.commons.vfs.util.MonitorOutputStream.close(MonitorOutputStream.java:63)
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:595)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:106)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:181)
> at
> org.apache.commons.vfs.provider.ftp.FtpFileObject.onChange(FtpFileObject.java:269)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.endOutput(AbstractFileObject.java:1325)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.endOutput(DefaultFileContent.java:459)
> at
> org.apache.commons.vfs.provider.DefaultFileContent.access$200(DefaultFileContent.java:44)
> at
> org.apache.commons.vfs.provider.DefaultFileContent$FileContentOutputStream.onClose(DefaultFileContent.java:616)
> ... 10 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-679) NullPointerException in FtpFileObject.doGetLastModifiedTime()
[
https://issues.apache.org/jira/browse/VFS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-679:
-
Summary: NullPointerException in FtpFileObject.doGetLastModifiedTime()
(was: FtpFileObject is not thread safe)
> NullPointerException in FtpFileObject.doGetLastModifiedTime()
> -
>
> Key: VFS-679
> URL: https://issues.apache.org/jira/browse/VFS-679
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: Nightly Builds, 2.2
>Reporter: Boris Petrov
>Priority: Blocker
>
> This is similar to https://issues.apache.org/jira/browse/VFS-294 but it is
> very old so I'm not sure how relevant it is.
> We're getting numerous exceptions like:
> {noformat}
> org.apache.commons.vfs2.FileSystemException: Could not determine the size of
> file "ftp://ftp.pbteu.com/VMRType.reg;.
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:134)
> ...
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetContentSize(FtpFileObject.java:449)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:132)
> ... 13 common frames omitted
> {noformat}
>
> And:
>
> {noformat}
> 10:21:15.427 [Thread-20] ERROR o.a.c.vfs2.impl.DefaultFileMonitor - Could not
> determine the last modified timestamp of "ftp://ftp.pbteu.com/VMRType.reg;.
> org.apache.commons.vfs2.FileSystemException: Could not determine the last
> modified timestamp of "ftp://ftp.pbteu.com/VMRType.reg;.
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getLastModifiedTime(DefaultFileContent.java:156)
> at
> org.apache.commons.vfs2.impl.DefaultFileMonitor$FileMonitorAgent.check(DefaultFileMonitor.java:526)
> at
> org.apache.commons.vfs2.impl.DefaultFileMonitor$FileMonitorAgent.access$200(DefaultFileMonitor.java:367)
> at
> org.apache.commons.vfs2.impl.DefaultFileMonitor.run(DefaultFileMonitor.java:330)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetLastModifiedTime(FtpFileObject.java:469)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getLastModifiedTime(DefaultFileContent.java:154)
> ... 4 common frames omitted
> {noformat}
>
> This is happening on 2.2 and on the current trunk. I'm not sure where to
> start digging from but this is a show-stopper for us. Any help is appreciated!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-674) Cannot close an FTP input stream without an exception
[
https://issues.apache.org/jira/browse/VFS-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-674.
--
Resolution: Fixed
Fix Version/s: 2.3
Applied a modified patch from Boris Petrov to avoid breaking binary
compatibility.
Please verify and close.
> Cannot close an FTP input stream without an exception
> -
>
> Key: VFS-674
> URL: https://issues.apache.org/jira/browse/VFS-674
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Boris Petrov
>Priority: Critical
> Labels: pull-request-available
> Fix For: 2.3
>
>
> The FTP server is FileZilla.
> 1. Get a stream instance from an FtpFileObject via the `getInputStream`
> method.
> 2. Read some bytes from the stream.
> 3. Close the stream via `stream.close()`.
> 4. If the stream has not been completely read, the FTP server sends a `426
> Connection closed; transfer aborted` response code.
> 5. `FtpFileObject::onClose` is called.
> 6. Eventually `FTPReply::isPositiveCompletion` is called.
> 7. Since the response code is outside the [200; 300) range it is considered
> an error.
> 8. A `FileSystemException` is thrown.
> The overall result is that when closing a stream that is not completely read
> an exception is thrown. Which is obviously wrong.
> A similar things happens with this piece of code:
> {code:java}
> try (FileContent content = ftpFileObject.getContent()) {
> // ..
> }
> {code}
> Is there an easy way we can patch this in VFS as this is a showstopper for us?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
