[jira] [Updated] (MATH-1427) Unreachable statements in Complex.abs()
[
https://issues.apache.org/jira/browse/MATH-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Nickerson updated MATH-1427:
--
Attachment: complex_abs.patch
> Unreachable statements in Complex.abs()
> ---
>
> Key: MATH-1427
> URL: https://issues.apache.org/jira/browse/MATH-1427
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: David Nickerson
>Priority: Minor
> Labels: easyfix, newbie, patch
> Attachments: complex_abs.patch
>
>
> This return statement in Complex.abs() is unreachable:
> {code:java}
> if (FastMath.abs(real) < FastMath.abs(imaginary)) {
> if (imaginary == 0.0) {
> return FastMath.abs(real);
> }
> {code}
> If imaginary == 0, then there's no way that the preceding condition would be
> true. There are two similar inner 'if' statements that were accidentally
> switched. Returned values are still correct, but performance suffers.
> The attached patch switches these back. Note that we're still protected from
> dividing by zero.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MATH-1427) Unreachable statements in Complex.abs()
David Nickerson created MATH-1427:
-
Summary: Unreachable statements in Complex.abs()
Key: MATH-1427
URL: https://issues.apache.org/jira/browse/MATH-1427
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: David Nickerson
Priority: Minor
This return statement in Complex.abs() is unreachable:
{code:java}
if (FastMath.abs(real) < FastMath.abs(imaginary)) {
if (imaginary == 0.0) {
return FastMath.abs(real);
}
{code}
If imaginary == 0, then there's no way that the preceding condition would be
true. There are two similar inner 'if' statements that were accidentally
switched. Returned values are still correct, but performance suffers.
The attached patch switches these back. Note that we're still protected from
dividing by zero.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COLLECTIONS-652) An obvious bug in CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COLLECTIONS-652.
--
Resolution: Fixed
Fix Version/s: 3.2.2
This was fixed in 3.2.2
> An obvious bug in CollectionUtils
> -
>
> Key: COLLECTIONS-652
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-652
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 3.2.1
> Environment: windows 7, jdk8. This bug is so obvious so I think it is
> nothing to do with environment
>Reporter: samray leung
>Priority: Minor
> Labels: easyfix
> Fix For: 3.2.2
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> In CollectionUtils.java:
> Line number: 1121
> /**
> * Removes the elements in remove from
> collection. That is, this
> * method returns a collection containing all the elements in
> c
> * that are not in remove. The cardinality of an element
> e
> * in the returned collection is the same as the cardinality of
> e
> * in collection unless remove contains
> e, in which
> * case the cardinality is zero. This method is useful if you do not wish
> to modify
> * the collection c and thus cannot call
> collection.removeAll(remove);.
> *
> * @param collection the collection from which items are removed (in the
> returned collection)
> * @param remove the items to be removed from the returned
> collection
> * @return a Collection containing all the elements of
> collection except
> * any elements that also occur in remove.
> * @throws NullPointerException if either parameter is null
> * @since Commons Collections 3.2
> */
> public static Collection removeAll(Collection collection, Collection
> remove) {
> return ListUtils.retainAll(collection, remove);
> }
> The method should call ListUtils.removeAll(Collection collection, Collection
> remove) instead of calling ListUtils.retailAll(collection,remove)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (COLLECTIONS-652) An obvious bug in CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb closed COLLECTIONS-652.
> An obvious bug in CollectionUtils
> -
>
> Key: COLLECTIONS-652
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-652
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 3.2.1
> Environment: windows 7, jdk8. This bug is so obvious so I think it is
> nothing to do with environment
>Reporter: samray leung
>Priority: Minor
> Labels: easyfix
> Fix For: 3.2.2
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> In CollectionUtils.java:
> Line number: 1121
> /**
> * Removes the elements in remove from
> collection. That is, this
> * method returns a collection containing all the elements in
> c
> * that are not in remove. The cardinality of an element
> e
> * in the returned collection is the same as the cardinality of
> e
> * in collection unless remove contains
> e, in which
> * case the cardinality is zero. This method is useful if you do not wish
> to modify
> * the collection c and thus cannot call
> collection.removeAll(remove);.
> *
> * @param collection the collection from which items are removed (in the
> returned collection)
> * @param remove the items to be removed from the returned
> collection
> * @return a Collection containing all the elements of
> collection except
> * any elements that also occur in remove.
> * @throws NullPointerException if either parameter is null
> * @since Commons Collections 3.2
> */
> public static Collection removeAll(Collection collection, Collection
> remove) {
> return ListUtils.retainAll(collection, remove);
> }
> The method should call ListUtils.removeAll(Collection collection, Collection
> remove) instead of calling ListUtils.retailAll(collection,remove)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (POOL-328) Documentation with repeated words (sources, tests, and examples)
[ https://issues.apache.org/jira/browse/POOL-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenzo Solano Martinez closed POOL-328. Solved with https://github.com/apache/commons-pool/pull/2 , changes were verified on master. > Documentation with repeated words (sources, tests, and examples) > > > Key: POOL-328 > URL: https://issues.apache.org/jira/browse/POOL-328 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.4.2 > Environment: All >Reporter: Lorenzo Solano Martinez >Priority: Trivial > Labels: documentaion, easyfix > Fix For: 2.4.3 > > Original Estimate: 1h > Remaining Estimate: 1h > > Some files with repeated -repeated- words in documentation ( sources, tests, > and examples ): > * src/main/java/org/apache/commons/pool2/BaseKeyedPooledObjectFactory.java > * src/main/java/org/apache/commons/pool2/PooledObject.java > * src/main/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java > * src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java > * src/site/xdoc/examples.xml > * src/test/java/org/apache/commons/pool2/impl/TestGenericKeyedObjectPool.java > * src/test/java/org/apache/commons/pool2/impl/TestGenericObjectPool.java -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (VFS-640) Synchronized AbstractOriginatingFileProvider.getFileSystem is too broad
L created VFS-640:
-
Summary: Synchronized
AbstractOriginatingFileProvider.getFileSystem is too broad
Key: VFS-640
URL: https://issues.apache.org/jira/browse/VFS-640
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1, 2.0
Reporter: L
Currently (rev. 1802455) this method looks like this:
{code:java}
protected synchronized FileSystem getFileSystem(final FileName rootName,
final FileSystemOptions fileSystemOptions)
throws FileSystemException
{
FileSystem fs = findFileSystem(rootName, fileSystemOptions);
if (fs == null)
{
// Need to create the file system, and cache it
fs = doCreateFileSystem(rootName, fileSystemOptions);
addFileSystem(rootName, fs);
}
return fs;
}
{code}
Given that there is a single instance of a provider per scheme, a very slow
server that is being accessed first time will block *all* other threads trying
to access some other resources via the same provider.
We have a server that takes sometimes 20-30 seconds in doCreateFileSystem. We
do not mind the thread trying to access this method taking that long, but
because of that "synchronized" we end up having multiple threads accessing
unrelated servers for the same scheme blocked.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCS-179) org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory not able to start server
[ https://issues.apache.org/jira/browse/JCS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-179: --- Assignee: Thomas Vandahl > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory not > able to start server > > > Key: JCS-179 > URL: https://issues.apache.org/jira/browse/JCS-179 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-2.1 > Environment: windows 7 >Reporter: Archer >Assignee: Thomas Vandahl > Labels: easyfix > Fix For: jcs-2.2 > > > The issue is on the > org.apache.commons.jcs.engine.control.CompositeCacheManager.java (configure > function). > for some reason InputStream is = getClass().getResourceAsStream( propFile ) > is giving access error. After reviewing source code, I would like to question > why doing a read of the file again? Doesn't the class already have the the > same properties loaded already? > steps to reproduce the issue: > 1. created a window batch file to start the RemoteCacheServerFactory > "c:\Program Files\Java\jdk1.8.0_92\bin\java" -classpath > C:\Apache\jcs-2.1-bin\commons-jcs-core\commons-jcs-core-2.1.jar;C:\javalib\apache-commons\commons-logging.jar > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory > cache.ccf > getting the following error. > Jun 16, 2017 2:47:05 PM > org.apache.commons.jcs.engine.control.CompositeCacheManager getUnconfiguredI > INFO: Instance is null, returning unconfigured instance > Jun 16, 2017 2:47:05 PM > org.apache.commons.jcs.engine.control.CompositeCacheManager configure > INFO: Creating cache manager from config file: cache.ccf > Exception in thread "main" java.rmi.RemoteException: Failed to read > configuration file [cache.ccf]; > org.apache.commons.jcs.access.exception.CacheException: Failed to > read configuration file [c > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.init(RemoteCacheServer.j > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.(RemoteCacheServer > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory.startup(RemoteCac > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory.startup(RemoteCac > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory.main(RemoteCacheS > Caused by: org.apache.commons.jcs.access.exception.CacheException: Failed to > read configuration file > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManag > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.createCacheManager(Remot > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.init(RemoteCacheServer.j -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCS-179) org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory not able to start server
[ https://issues.apache.org/jira/browse/JCS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-179. Resolution: Fixed Fix Version/s: jcs-2.2 Fixed in SVN > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory not > able to start server > > > Key: JCS-179 > URL: https://issues.apache.org/jira/browse/JCS-179 > Project: Commons JCS > Issue Type: Bug > Components: RMI Remote Cache >Affects Versions: jcs-2.1 > Environment: windows 7 >Reporter: Archer >Assignee: Thomas Vandahl > Labels: easyfix > Fix For: jcs-2.2 > > > The issue is on the > org.apache.commons.jcs.engine.control.CompositeCacheManager.java (configure > function). > for some reason InputStream is = getClass().getResourceAsStream( propFile ) > is giving access error. After reviewing source code, I would like to question > why doing a read of the file again? Doesn't the class already have the the > same properties loaded already? > steps to reproduce the issue: > 1. created a window batch file to start the RemoteCacheServerFactory > "c:\Program Files\Java\jdk1.8.0_92\bin\java" -classpath > C:\Apache\jcs-2.1-bin\commons-jcs-core\commons-jcs-core-2.1.jar;C:\javalib\apache-commons\commons-logging.jar > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory > cache.ccf > getting the following error. > Jun 16, 2017 2:47:05 PM > org.apache.commons.jcs.engine.control.CompositeCacheManager getUnconfiguredI > INFO: Instance is null, returning unconfigured instance > Jun 16, 2017 2:47:05 PM > org.apache.commons.jcs.engine.control.CompositeCacheManager configure > INFO: Creating cache manager from config file: cache.ccf > Exception in thread "main" java.rmi.RemoteException: Failed to read > configuration file [cache.ccf]; > org.apache.commons.jcs.access.exception.CacheException: Failed to > read configuration file [c > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.init(RemoteCacheServer.j > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.(RemoteCacheServer > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory.startup(RemoteCac > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory.startup(RemoteCac > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServerFactory.main(RemoteCacheS > Caused by: org.apache.commons.jcs.access.exception.CacheException: Failed to > read configuration file > at > org.apache.commons.jcs.engine.control.CompositeCacheManager.configure(CompositeCacheManag > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.createCacheManager(Remot > at > org.apache.commons.jcs.auxiliary.remote.server.RemoteCacheServer.init(RemoteCacheServer.j -- This message was sent by Atlassian JIRA (v6.4.14#64029)
