[jira] [Commented] (POOL-209) SharedPoolDataSource does not handle null keys correctly
[ https://issues.apache.org/jira/browse/POOL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175351#comment-13175351 ] Greg Roberts commented on POOL-209: --- I've just started getting Attempted to use PooledConnection after closed() was called. errors after moving to jTDS 1.2.5 and dbcp 1.4. I'm also using Torque 3.3 and java 1.6. Has there been any resolution to this problem? Is there a workaround/fix of some kind? Thanks. SharedPoolDataSource does not handle null keys correctly Key: POOL-209 URL: https://issues.apache.org/jira/browse/POOL-209 Project: Commons Pool Issue Type: Bug Environment: Windows, java version 1.6.0_06, Torque 3.3 (DBCP 1.4, jTDS 1.2.5) Reporter: Gabor Horvath Attachments: GenericKeyedObjectPool.java GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails (line ~1200). I guess invalidation would be needed for objects which are not newly created (newlyCreated flag in the code). Scenario: 1.) DB connection put into pool 2.) Attempt to reuse connection (borrowObject) 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level but connection remains in the pool 4.) Subsequent attempts to reuse the connection causes java.sql.SQLException: Invalid state, the Connection object is closed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-728) Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than 2*dim+1
[ https://issues.apache.org/jira/browse/MATH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175424#comment-13175424 ] Gilles commented on MATH-728: - It would be very useful if you could provide unit tests that cover the still unexplored code paths (cf. lines containing throw new PathIsExploredException();). Thanks in advance for your contributions. Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than 2*dim+1 -- Key: MATH-728 URL: https://issues.apache.org/jira/browse/MATH-728 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Environment: Mac Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11M3527) Reporter: Bruce A Johnson I've been having trouble getting BOBYQA to minimize a function (actually a non-linear least squares fit) so as one change I increased the number of interpolation points. It seems that anything larger than 2*dim+1 causes an error (typically at line 1662 interpolationPoints.setEntry(nfm, ipt, interpolationPoints.getEntry(ipt, ipt)); I'm guessing there is an off by one error in the translation from FORTRAN. Changing the BOBYQAOptimizerTest as follows (increasing number of interpolation points by one) will cause failures. Bruce Index: src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java === --- src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java (revision 1221065) +++ src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java (working copy) @@ -258,7 +258,7 @@ //RealPointValuePair result = optim.optimize(10, func, goal, startPoint); final double[] lB = boundaries == null ? null : boundaries[0]; final double[] uB = boundaries == null ? null : boundaries[1]; -BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 1); +BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 2); RealPointValuePair result = optim.optimize(maxEvaluations, func, goal, startPoint, lB, uB); //System.out.println(func.getClass().getName() + = // + optim.getEvaluations() + f(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VALIDATOR-253) Change groupId to org.apache.commons
[ https://issues.apache.org/jira/browse/VALIDATOR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175484#comment-13175484 ] Gunnar Gustavsson commented on VALIDATOR-253: - A tech question. How is deploys to repo1.maven.org performed? It's seems not to be performed using maven since there are errors: http://repo1.maven.org/maven2/commons-daemon/commons-daemon/1.0.3/commons-daemon-1.0.3.pom contains groupId org.apache.commons. Change groupId to org.apache.commons Key: VALIDATOR-253 URL: https://issues.apache.org/jira/browse/VALIDATOR-253 Project: Commons Validator Issue Type: Task Reporter: Paul Benedict Assignee: Nick Burch Fix For: 1.4 Some existing Commons projects have made the POM move to org.apache.commons with their new releases. http://repo.mergere.com/maven2/org/apache/commons/ I think a 1.4 release is a good time to change the groupId as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-208) Support Java 1.5 Generics in version 1.x.
[ https://issues.apache.org/jira/browse/POOL-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved POOL-208. -- Resolution: Fixed Assignee: Gary D. Gregory In SVN. Support Java 1.5 Generics in version 1.x. - Key: POOL-208 URL: https://issues.apache.org/jira/browse/POOL-208 Project: Commons Pool Issue Type: Improvement Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: C:\Java\apache-maven-3.0.3\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_29\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 1.6 Support Java 1.5 Generics in version 1.x. Create a 1.x release with generics. Right now, that would be 1.6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-473) Frequency: new option: NON-sorted
[ https://issues.apache.org/jira/browse/MATH-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-473: - Assignee: (was: Phil Steitz) Frequency: new option: NON-sorted - Key: MATH-473 URL: https://issues.apache.org/jira/browse/MATH-473 Project: Commons Math Issue Type: Improvement Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1 Reporter: Dan Checkoway Fix For: 3.0 Attachments: MATH-473.patch I have a request for enhancement on org.apache.commons.math.stat.Frequency. I would like to be able to specify that the the backing map NOT be sorted. Right now it uses TreeMap. I would like to have the option of specifying that sorting is not important, and would in fact hinder performance, and a plain old HashMap should be used instead. i.e. constructor such as: public Frequency(boolean sorted); If sorted is true, use a TreeMap. If sorted is false, use a HashMap. Is this feasible? I'd be happy to contribute a patch if that would help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-575) Exceptions in genetics package or not consistent with the rest of [math]
[ https://issues.apache.org/jira/browse/MATH-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-575: - Assignee: (was: Phil Steitz) Exceptions in genetics package or not consistent with the rest of [math] Key: MATH-575 URL: https://issues.apache.org/jira/browse/MATH-575 Project: Commons Math Issue Type: Bug Affects Versions: 2.0, 2.1, 2.2 Reporter: Phil Steitz Priority: Minor Fix For: 3.0 InvalidRepresentationException is checked and non-localized. This exception should be placed in the [math] hierarchy. The AbstractListChromosome constructor also throws a non-localised IAE, which should be replaced by an appropriate [math] exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-474) Frequency: new method: merge(Frequency)
[ https://issues.apache.org/jira/browse/MATH-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-474: - Assignee: (was: Phil Steitz) Frequency: new method: merge(Frequency) --- Key: MATH-474 URL: https://issues.apache.org/jira/browse/MATH-474 Project: Commons Math Issue Type: Improvement Reporter: Dan Checkoway Fix For: 3.0 Attachments: MATH-474.patch I'd like to propose an enhancement to org.apache.commons.math.stat.Frequency. I need to merge multiple Frequency objects, and it would be great if Frequency had inherent support for this, such as: public void merge(Frequency other); public void merge(CollectionFrequency others); I'd be happy to submit a patch if that would help... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-588) Weighted Mean evaluation may not have optimal numerics
[
https://issues.apache.org/jira/browse/MATH-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-588:
-
Assignee: (was: Phil Steitz)
Weighted Mean evaluation may not have optimal numerics
--
Key: MATH-588
URL: https://issues.apache.org/jira/browse/MATH-588
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1, 2.2
Reporter: Phil Steitz
Fix For: 3.0
I recently got this in a test run
{code}
testWeightedConsistency(org.apache.commons.math.stat.descriptive.moment.MeanTest)
Time elapsed: 0 sec FAILURE!
java.lang.AssertionError: expected:0.002282165958997601 but
was:0.002282165958997157
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:441)
at
org.apache.commons.math.TestUtils.assertRelativelyEquals(TestUtils.java:178)
at
org.apache.commons.math.TestUtils.assertRelativelyEquals(TestUtils.java:153)
at
org.apache.commons.math.stat.descriptive.UnivariateStatisticAbstractTest.testWeightedConsistency(UnivariateStatisticAbstractTest.java:170)
{code}
The correction formula used to compute the unweighted mean may not be
appropriate or optimal in the presence of weights:
{code}
// Compute initial estimate using definitional formula
double sumw = sum.evaluate(weights,begin,length);
double xbarw = sum.evaluate(values, weights, begin, length) / sumw;
// Compute correction factor in second pass
double correction = 0;
for (int i = begin; i begin + length; i++) {
correction += weights[i] * (values[i] - xbarw);
}
return xbarw + (correction/sumw);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
