[jira] [Updated] (MATH-588) Weighted Mean evaluation may not have optimal numerics

2011-12-23 Thread Phil Steitz (Updated) (JIRA)

 [ 
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




[jira] [Updated] (MATH-474) Frequency: new method: merge(Frequency)

2011-12-23 Thread Phil Steitz (Updated) (JIRA)

 [ 
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(Collection 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-575) Exceptions in genetics package or not consistent with the rest of [math]

2011-12-23 Thread Phil Steitz (Updated) (JIRA)

 [ 
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-473) Frequency: new option: NON-sorted

2011-12-23 Thread Phil Steitz (Updated) (JIRA)

 [ 
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] (DBCP-317) Findbugs: Class doesn't override equals in superclass

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-317:
-

Fix Version/s: (was: 1.4.1)
   (was: 1.3.1)
   2.0

> Findbugs: Class doesn't override equals in superclass
> -
>
> Key: DBCP-317
> URL: https://issues.apache.org/jira/browse/DBCP-317
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.0
>
>
> Findbugs: Class doesn't override equals in superclass - 8 instances
> "This class extends a class that defines an equals method and adds fields, 
> but doesn't define an equals method itself. Thus, equality on instances of 
> this class will ignore the identity of the subclass and the added fields. Be 
> sure this is what is intended, and that you don't need to override the equals 
> method. Even if you don't need to override the equals method, consider 
> overriding it anyway to document the fact that the equals method for the 
> subclass just return the result of invoking super.equals(o). "
> Classes (superclass) are:
> cpdsadapter.ConnectionImpl doesn't override DelegatingConnection.equals
> datasources.LRUMap doesn't override SequencedHashMap.equals
> managed.ManagedConnection doesn't override DelegatingConnection.equals
> managed.PoolableManagedConnection  doesn't override 
> DelegatingConnection.equals
> PoolableCallableStatement doesn't override DelegatingCallableStatement.equals
> PoolableConnection doesn't override DelegatingConnection.equals
> PoolablePreparedStatement doesn't override DelegatingPreparedStatement.equals
> PoolingConnection doesn't override DelegatingConnection.equals

--
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] (DBCP-319) Make private fields final where possible

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-319:
-

Fix Version/s: (was: 1.4.1)
   (was: 1.3.1)
   2.0

> Make private fields final where possible
> 
>
> Key: DBCP-319
> URL: https://issues.apache.org/jira/browse/DBCP-319
> Project: Commons Dbcp
>  Issue Type: Improvement
>Reporter: Sebb
> Fix For: 2.0
>
> Attachments: DBCP-319-private-final.patch
>
>
> Several private fields could be made final:
> AbandonedTrace.config
> AbandonedTrace.AbandonedObjectException._createdTime
> cpdsadapter.PooledConnectionImpl:
> * connection
> * delegatingConnection
> * eventListeners
> * statementEventListeners
> * pstmtPool is protected, but could probably be made final if it were not for 
> the API change that would imply
> cpdsadapter.PooledConnectionImpl.PStmtKey (nested class, variables are 
> protected, but might as well be private)
> * all of its fields could be made final
> datasources.[Keyed]CPDSConnectionFactory.validatingMap
> datasources.[Keyed]CPDSConnectionFactory.pcMap
> managed.PoolableManagedConnection.transactionRegistry
> managed.PoolableManagedConnectionFactory.transactionRegistry
> managed.TransactionRegistry.transactionManager|caches|xaResources
> .AbandonedObjectPool.config|trace

--
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] (DBCP-322) CPDSConnectionFactory.validateObject(Object) ignores Throwable

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-322:
-

Fix Version/s: (was: 1.4.1)
   (was: 1.3.1)
   2.0

This is a behavior change that could conceivably break some applications, so 
pushing to 2.0

> CPDSConnectionFactory.validateObject(Object) ignores Throwable
> --
>
> Key: DBCP-322
> URL: https://issues.apache.org/jira/browse/DBCP-322
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 1.2, 1.2.1, 1.2.2, 1.3, 1.4
>Reporter: Sebb
> Fix For: 2.0
>
>
> CPDSConnectionFactory.validateObject(Object) catches and ignores Throwable, 
> which is a bit excessive. For example:
> {code}
> if (rset != null) {
> try {
> rset.close();
> } catch (Throwable t) {
> // ignore
> }
> }
> {code}
> close() can only throw SQLException, and that is all that should be ignored. 
> In particular, ThreadDeath should never be ignored.
> Same applies to KeyedCPDSConnectionFactory.
> Basic[Managed]Datasource also catch Throwable, but rethrow it as 
> SQLNestedException.
> This is a bit better, but there's still the problem with ThreadDeath.

--
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] (DBCP-363) dbcp bundle should use DynamicImport

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-363:
-

Fix Version/s: 1.4.1

> dbcp bundle should use DynamicImport
> 
>
> Key: DBCP-363
> URL: https://issues.apache.org/jira/browse/DBCP-363
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 1.3, 1.4
>Reporter: Felix Mayerhuber
> Fix For: 1.4.1
>
>
> The bundle provided in the maven central of the commons.dbcp doesn't have a 
> DynamicImport defined. This resolves in following error:
> If you want to use a BasicDataSource class as dataSource and the class is 
> provided by the osgi environment (equinox, ...) the dataSource is not able to 
> be created due to a ClassNotFoundException. If the bundle would have set 
> DynamicImport it works. (I had to change from your bundle to the commons.dbcp 
> bundle provided by servicemix, because there the DynamicImport is set)

--
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] (DBCP-364) BasicDataSourceFactory#createDataSource return signature should be BasicDataSourceFactory so that caller can invoke methods not declared in DataSource (e.g., close())

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-364:
-

Fix Version/s: 2.0

> BasicDataSourceFactory#createDataSource return signature should be 
> BasicDataSourceFactory so that caller can invoke methods not declared in 
> DataSource (e.g., close())
> --
>
> Key: DBCP-364
> URL: https://issues.apache.org/jira/browse/DBCP-364
> Project: Commons Dbcp
>  Issue Type: Improvement
>Reporter: ori
>Priority: Trivial
> Fix For: 2.0
>
>
> BasicDataSourceFactory#createDataSource currently returns a DataSource 
> instance.
> It should a return type of BasicDataSourceFactory. Otherwise the caller has 
> to cast it to invoke close (and other methods specific to the implementation).

--
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] (DBCP-373) Ability to configure upper bound on total number of connections managed by pooled data sources across all keys (user/password).

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-373:
-

Fix Version/s: 2.0

> Ability to configure upper bound on total number of connections managed by 
> pooled data sources across all keys (user/password).
> ---
>
> Key: DBCP-373
> URL: https://issues.apache.org/jira/browse/DBCP-373
> Project: Commons Dbcp
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Scott Cameron
> Fix For: 2.0
>
>
> For a discussion about this request, please refer to: 
> http://www.mail-archive.com/user@commons.apache.org/msg07215.html.
> In general, it feels like SharedPoolDataSource and PerUserPoolDataSource 
> could be made much more powerful and flexible by exposing as much of the 
> configurability of the underlying ObjectPool as possible.  It seems to me 
> that if consumers are going to want to customize behavior it is very likely 
> that it is the ObjectPool that they will want to tweak.  Exposing the power 
> of the inner pool would be really useful.
> But if that doesn't make sense, at least allowing a global cap on the total 
> number of connections across all keys in the pool data source would solve at 
> least the problem I describe in the mailing list post.

--
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] (DBCP-367) minIdle's document is not correct

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-367:
-

Fix Version/s: 1.4.1

> minIdle's document is not correct
> -
>
> Key: DBCP-367
> URL: https://issues.apache.org/jira/browse/DBCP-367
> Project: Commons Dbcp
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Ken Tatsushita
>Priority: Trivial
> Fix For: 1.4.1
>
> Attachments: configuration.xml.patch
>
>
> Hi experts! 
> minIdle does not work when not running evictor thread.
> However, there is no description about it in the document.
> I think that need to add a note in document.
> I made a patch.
> Best regards.

--
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] (DBCP-369) Exception when using SharedPoolDataSource concurrently

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-369:
-

Fix Version/s: 1.4.1

> Exception when using SharedPoolDataSource concurrently
> --
>
> Key: DBCP-369
> URL: https://issues.apache.org/jira/browse/DBCP-369
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: Java Hotspot Server VM 1.6.0_07, Linux
>Reporter: Michael Pradel
> Fix For: 1.4.1
>
>
> Hi,
> I get a ConcurrentModificationException when using instances of 
> SharedPoolDataSource concurrently. The problem occurs when one thread calls 
> setDataSourceName() while another thread calls close(), either on the same 
> instance of SharedPoolDataSource or on different instances. I'll attach a 
> short example program that leads to an exception for almost every run on my 
> machine.
> The cause of the exception seems to be in InstanceKeyObjectFactory. 
> registerNewInstance() is synchronized, but removeInstance() isn't. This 
> allows concurrent accesses to the non-thread-safe 'instanceMap'.
> Is this a bug? Or are SharedPoolDataSource and InstanceKeyObjectFactory not 
> supposed to be thread-safe?
> Thanks!
> import java.util.ArrayList;
> import org.apache.commons.dbcp.datasources.SharedPoolDataSource;
> public class SharedPoolDataSourceTest {
>   public static void main(String[] args) {
>   new SharedPoolDataSourceTest().run();
>   }
>   
>   private void run() {
>   final ArrayList dataSources = new 
> ArrayList();
>   for (int j = 0; j < 1; j++) {
>   SharedPoolDataSource dataSource = new 
> SharedPoolDataSource();
>   dataSources.add(dataSource);
>   }
>   
>   Thread t1 = new Thread(new Runnable() {
>   public void run() {
>   for (SharedPoolDataSource dataSource : 
> dataSources) {
>   dataSource.setDataSourceName("a");  
>   }   
>   }
>   });
>   Thread t2 = new Thread(new Runnable() {
>   public void run() {
>   for (SharedPoolDataSource dataSource : 
> dataSources) {
>   try { dataSource.close(); } catch 
> (Exception e) {}  
>   }
>   
>   }
>   });
>   t1.start();
>   t2.start();
>   try {
>   t1.join();
>   t2.join();
>   } catch (InterruptedException ie) {}
>   }   
> }
> Exception in thread "Thread-0" java.util.ConcurrentModificationException
>   at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
>   at java.util.HashMap$KeyIterator.next(HashMap.java:828)
>   at 
> org.apache.commons.dbcp.datasources.InstanceKeyObjectFactory.registerNewInstance(InstanceKeyObjectFactory.java:51)
>   at 
> org.apache.commons.dbcp.datasources.InstanceKeyDataSource.setDataSourceName(InstanceKeyDataSource.java:246)
>   at 
> potentialBugs.SharedPoolDataSourceTest$1.run(SharedPoolDataSourceTest.java:23)
>   at java.lang.Thread.run(Thread.java:619)

--
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] (DBCP-361) BasicManagedDataSource optional transaction enlistment

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-361:
-

Fix Version/s: 2.0

> BasicManagedDataSource optional transaction enlistment
> --
>
> Key: DBCP-361
> URL: https://issues.apache.org/jira/browse/DBCP-361
> Project: Commons Dbcp
>  Issue Type: New Feature
>Reporter: Aaron Hamid
> Fix For: 2.0
>
>
> It would be nice to not automatically enlist connections in a transaction.  I 
> have found automatic enlistment can be problematic when using another 
> transaction API such as Spring's declarative transactions 
> (JtaTransactionManager).  It appears Spring may create a second, wrapping 
> transaction.  With Oracle this leads to: ORA-02089: COMMIT is not allowed in 
> a subordinate session.
> E.g. see Bitronix setAutomaticEnlistingEnabled 
> http://btm.codehaus.org/api/1.3.3/bitronix/tm/resource/common/ResourceBean.html#setAutomaticEnlistingEnabled(boolean)

--
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] (DBCP-368) determine which connections to hold in pool by relative value

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-368:
-

Fix Version/s: 2.0

> determine which connections to hold in pool by relative value
> -
>
> Key: DBCP-368
> URL: https://issues.apache.org/jira/browse/DBCP-368
> Project: Commons Dbcp
>  Issue Type: New Feature
>Reporter: Philip Williams
> Fix For: 2.0
>
>
> Situation: a Firebird-Classic database (each connection has independent 
> metadata cache), in a metadata-heavy environment; many "quick" actions will 
> never force the database server to load full metadata, but a few will, in our 
> case resulting in 200MB of metadata cache in memory (takes about 3 seconds to 
> load, visible latency to the user); any connection that has done this is 
> "more valuable" to us, and we'd prefer to keep those connections in the pool, 
> and remove idle connections which haven't incurred this cost yet and are 
> relatively cheap to recreate later if our load increases. Doing this is 
> preferable to forcing ALL connections to load metadata at start, as this 
> means the pool will always have a startup cost (in time), and the server will 
> likely use more memory than really necessary.
> Proposal: add new configuration parameter; if set, run the SQL string and get 
> back a single-column, single-row result-set containing an arbitrary "value" 
> as determined by the connection; prefer to close the lowest(?)-value 
> connections first, to get down to the configured minIdle. Would require 
> querying each open connection, when the pool is over-full, to determine which 
> ones are most valuable. If not set, use current algorithm (based on age?).

--
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] (DBCP-372) Statement Leak occurs when batch update is used.

2011-12-21 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/DBCP-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated DBCP-372:
-

Fix Version/s: 1.4.1

> Statement Leak occurs when batch update is used.
> 
>
> Key: DBCP-372
> URL: https://issues.apache.org/jira/browse/DBCP-372
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 1.3, 1.4
> Environment: Oracle 11g
>Reporter: Naozumi Taromaru
>Priority: Critical
> Fix For: 1.4.1
>
>
> org.apache.commons.dbcp.PoolablePreparedStatement#passivate()
> execute clearBatch().
> (DBCP-264)
> But this clearBatch() throw SQLException.
> (DelegatingStatement#checkOpen() throw SQLException, because _closed is true.)
> The result,
> the PoolablePreparedStatement doesn't return to pool, and
> the PoolablePreparedStatement doesn't execute PreparedStatement#close().
> When a lot of data is processed, 
> in the case of Oracle
>  * ORA-00604
>  * ORA-01000
> occurs.
> Proposal:
> "clearBatch();" in passivate() method
> changes as follows.
> batchAdded = false;
> getInnermostDelegate().clearBatch();

--
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-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound

2011-12-20 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-724:
-

Summary: RandomDataImpl.nextInt does not distribute uniformly for negative 
lower bound  (was: 1)

> RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
> -
>
> Key: MATH-724
> URL: https://issues.apache.org/jira/browse/MATH-724
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2
>Reporter: Dennis Hendriks
> Fix For: 3.0
>
> Attachments: NextIntTest3.java, NextIntUniformTest.java, 
> NextUniformTest3.java, math-724-v2.patch, math-724-v3.patch, math-724.patch
>
>
> When using the RandomDataImpl.nextInt function to get a uniform sample in a 
> [lower, upper] interval, when the lower value is less than zero, the output 
> is not uniformly distributed, as the lowest value is practically never 
> returned.
> See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. 
> For several values between 0 and 1, testNextIntUniform1 prints the return 
> value of RandomDataImpl.nextInt (as double and as int). We see that -2 
> through 5 are returned several times. The -3 value however, is only returned 
> for 0.0, and is thus under-respresented in the integer samples. The output of 
> test method testNextIntUniform2 also clearly shows that value -3 is never 
> sampled.

--
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-724) 1

2011-12-20 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-724:
-

Affects Version/s: (was: Nightly Builds)
   1.0
   1.1
   1.2
   2.0
   2.1
   2.2
Fix Version/s: 3.0
  Summary: 1  (was: RandomDataImpl.nextInt does not distribute 
uniformly for negative lower bound)

> 1
> -
>
> Key: MATH-724
> URL: https://issues.apache.org/jira/browse/MATH-724
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2
>Reporter: Dennis Hendriks
> Fix For: 3.0
>
> Attachments: NextIntTest3.java, NextIntUniformTest.java, 
> NextUniformTest3.java, math-724-v2.patch, math-724-v3.patch, math-724.patch
>
>
> When using the RandomDataImpl.nextInt function to get a uniform sample in a 
> [lower, upper] interval, when the lower value is less than zero, the output 
> is not uniformly distributed, as the lowest value is practically never 
> returned.
> See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. 
> For several values between 0 and 1, testNextIntUniform1 prints the return 
> value of RandomDataImpl.nextInt (as double and as int). We see that -2 
> through 5 are returned several times. The -3 value however, is only returned 
> for 0.0, and is thus under-respresented in the integer samples. The output of 
> test method testNextIntUniform2 also clearly shows that value -3 is never 
> sampled.

--
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-720) RandomDataImpl uses both JDKRandomGenerator and Well19937c, while contract/javadoc only specifies Well19937c.

2011-12-11 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-720:
-

Affects Version/s: (was: 3.0)
   Nightly Builds
Fix Version/s: 3.0

> RandomDataImpl uses both JDKRandomGenerator and Well19937c, while 
> contract/javadoc only specifies Well19937c.
> -
>
> Key: MATH-720
> URL: https://issues.apache.org/jira/browse/MATH-720
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: Nightly Builds
>Reporter: Dennis Hendriks
>  Labels: random, seed
> Fix For: 3.0
>
> Attachments: TestRandom.java
>
>
> See attached unit test. I create a distribution, sample it (not printed), set 
> the seed to 0, and then print the next sample. I also create the same 
> distribution again, set the seed to 0, and then print the next sample. I 
> expect the same sample, as in both cases the seed was set to 0, just before 
> sampling. I however get this output:
> {code}
> 5
> 4
> {code}
> The problem is in the org.apache.commons.math.random.RandomDataImpl class:
>  - The RandomDataImpl(RandomGenerator rand) constructor states in javadoc: 
> "@param rand the source of (non-secure) random data (may be null, resulting 
> in default JDK-supplied generator)"
>  - reSeed(long seed) method does: if (rand == null) rand = new 
> JDKRandomGenerator();
>  - reSeed() method does: if (rand == null) rand = new JDKRandomGenerator();
>  - class javadoc states: "If no RandomGenerator is provided in 
> the constructor, the default is to use a Well19937c generator."
>  - getRan() does: if (rand == null) rand = new 
> Well19937c(System.currentTimeMillis() + System.identityHashCode(this));
>  - getRan() states in javadoc: "Creates and initializes a default generator 
> if null. Uses a Well19937c generator with System.currentTimeMillis() + 
> System.identityHashCode(this)) as the default seed."
> It seems that only Well19937c should be used, but the constructor javadoc, 
> and the implementation of the reSeed methods was not updated to match this. I 
> think the partial changes were done in MATH-701, more specifically, in commit 
> [1197626] (and related commit [1197716]).

--
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-650) FastMath has static code which slows the first access to FastMath

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-650:
-

Fix Version/s: 3.0

> FastMath has static code which slows the first access to FastMath
> -
>
> Key: MATH-650
> URL: https://issues.apache.org/jira/browse/MATH-650
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
> Environment: Android 2.3 (Dalvik VM with JIT)
>Reporter: Alexis Robert
>Priority: Minor
> Fix For: 3.0
>
> Attachments: FastMathLoadCheck.java, LucTestPerformance.java
>
>
> Working on an Android application using Orekit, I've discovered that a simple 
> FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the 
> first time it's called). I've launched the Android profiling tool (traceview) 
> and the problem seems to be linked with the static portion of FastMath code 
> named "// Initialize tables"
> The timing resulted in :
> - FastMath.slowexp (40.8%)
> - FastMath.expint (39.2%)
>  \- FastMath.quadmult() (95.6% of expint)
> - FastMath.slowlog (18.2%)
> Hoping that would help
> Thanks!
> Alexis Robert

--
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-703) Splitting up the distribution hierarchy

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-703:
-

Affects Version/s: 2.2
Fix Version/s: 3.0

> Splitting up the distribution hierarchy
> ---
>
> Key: MATH-703
> URL: https://issues.apache.org/jira/browse/MATH-703
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Christian Winter
>Priority: Minor
> Fix For: 3.0
>
> Attachments: MATH-703_patch.zip
>
>
> As discussed on the mailing list 
> (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html),
>  the distribution interfaces should be restructured.
> The most important point is to create one root interface for each domain. 
> There should *not* be a common super-interace because different domains 
> require different functionality. Additionally, a super-inferface would 
> require to parametrize the domain which makes things more complicated (e.g., 
> "double" would have to be replaced by "Double"). Currently, Commons Math 
> supports distributions with real domain and distributions with integer 
> domain. Thus there will be the interfaces RealDistribution and 
> IntegerDistribution.
> Another point is to drop the special cases of distributions with real domain 
> in order to simplify the structure. There won't be an interface for 
> absolutely continuous distributions, and there won't be an interface for 
> discrete distributions on the real domain. All the functionality required by 
> the special cases can be defined in RealDistribution.

--
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-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-699:
-

Affects Version/s: (was: 3.0)
   2.2
Fix Version/s: 3.0

> inverseCumulativeDistribution fails with cumulative distribution having a 
> plateau
> -
>
> Key: MATH-699
> URL: https://issues.apache.org/jira/browse/MATH-699
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>Priority: Minor
> Fix For: 3.0
>
> Attachments: AbstractContinuousDistributionTest.java, 
> inv-cum-new-impl.zip
>
>
> This bug report follows MATH-692. The attached unit test fails. As required 
> by the definition in MATH-692, the lower-bound of the interval on which the 
> cdf is constant should be returned. This is not so at the moment.

--
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-691) Statistics.setVarianceImpl makes getStandardDeviation produce NaN

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-691:
-

Fix Version/s: 3.0
 Assignee: Phil Steitz

> Statistics.setVarianceImpl makes getStandardDeviation produce NaN
> -
>
> Key: MATH-691
> URL: https://issues.apache.org/jira/browse/MATH-691
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows 7 64-bit, java version 1.6.0_23
>Reporter: Warren Tang
>Assignee: Phil Steitz
>Priority: Minor
> Fix For: 3.0
>
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> Invoking SummaryStatistics.setVarianceImpl(new Variance(true/false) makes 
> getStandardDeviation produce NaN. The code to reproduce it:
> {code:java}
> int[] scores = {1, 2, 3, 4};
> SummaryStatistics stats = new SummaryStatistics();
> stats.setVarianceImpl(new Variance(false)); //use "population variance"
> for(int i : scores) {
>   stats.addValue(i);
> }
> double sd = stats.getStandardDeviation();
> System.out.println(sd);
> {code}
> A workaround suggested by Mikkel is:
> {code:java}
>   double sd = FastMath.sqrt(stats.getSecondMoment() / stats.getN());
> {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




[jira] [Updated] (MATH-704) One of Variance.evaluate() methods does not work correctly

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-704:
-

Fix Version/s: 3.0

> One of Variance.evaluate() methods does not work correctly
> --
>
> Key: MATH-704
> URL: https://issues.apache.org/jira/browse/MATH-704
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: Java 1.6
>Reporter: Leonid Ilyevsky
> Fix For: 3.0
>
>
> The method 
> org.apache.commons.math.stat.descriptive.moment.Variance.evaluate(double[] 
> values, double[] weights, double mean, int begin, int length) does not work 
> properly. Looks loke it ignores the length parameter and grabs the whole 
> dataset.
> Similar method in Mean class seems to work.
> I did not check other methods taking the part of the array; they may have the 
> same problem.
> Workaround: I had to shrink my arrays and use the method without the length.

--
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-665) QRDecomposition does not have a singularity threshold

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-665:
-

Fix Version/s: 3.0

> QRDecomposition does not have a singularity threshold
> -
>
> Key: MATH-665
> URL: https://issues.apache.org/jira/browse/MATH-665
> Project: Commons Math
>  Issue Type: Bug
>Reporter: Phil Steitz
> Fix For: 3.0
>
>
> QRDecompositionImpl tests elements of rDiag for exact equality to 0 in 
> checking singularity.  A singularity threshold should be defined for this 
> class and used in the singularity test.

--
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-449) Storeless covariance

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-449:
-

Assignee: (was: Phil Steitz)

> Storeless covariance
> 
>
> Key: MATH-449
> URL: https://issues.apache.org/jira/browse/MATH-449
> Project: Commons Math
>  Issue Type: Improvement
>Reporter: Patrick Meyer
> Fix For: 3.1
>
> Attachments: MATH-449.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently there is no storeless version for computing the covariance. 
> However, Pebay (2008) describes algorithms for on-line covariance 
> computations, [http://infoserve.sandia.gov/sand_doc/2008/086212.pdf]. I have 
> provided a simple class for implementing this algorithm. It would be nice to 
> have this integrated into org.apache.commons.math.stat.correlation.Covariance.
> {code}
> //This code is granted for inclusion in the Apache Commons under the terms of 
> the ASL.
> public class StorelessCovariance{
> private double deltaX = 0.0;
> private double deltaY = 0.0;
> private double meanX = 0.0;
> private double meanY = 0.0;
> private double N=0;
> private Double covarianceNumerator=0.0;
> private boolean unbiased=true;
> public Covariance(boolean unbiased){
>   this.unbiased = unbiased;
> }
> public void increment(Double x, Double y){
> if(x!=null & y!=null){
> N++;
> deltaX = x - meanX;
> deltaY = y - meanY;
> meanX += deltaX/N;
> meanY += deltaY/N;
> covarianceNumerator += ((N-1.0)/N)*deltaX*deltaY;
> }
> 
> }
> public Double getResult(){
> if(unbiased){
> return covarianceNumerator/(N-1.0);
> }else{
> return covarianceNumerator/N;
> }
> }   
> }
> {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




[jira] [Updated] (MATH-287) Add support for weighted descriptive statistics

2011-11-26 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated MATH-287:
-

Assignee: (was: Phil Steitz)

> Add support for weighted descriptive statistics
> ---
>
> Key: MATH-287
> URL: https://issues.apache.org/jira/browse/MATH-287
> Project: Commons Math
>  Issue Type: New Feature
>Affects Versions: 2.0
>Reporter: Matthew Rowles
>Priority: Minor
> Fix For: 3.1
>
> Attachments: weightTests.patch, weighted.patch
>
>
> Add support for weighted descriptive statistics, such as weighted variance.
> An example method call would be Variance.evaluate(double[] values, double[] 
> weights, int begin, int length)
> - Suggested by  mickey...@taosnet.com on the mailing list.

--
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] (POOL-190) Add API BaseObjectPool.isOpen()

2011-11-14 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-190:
-

Issue Type: Bug  (was: New Feature)

> Add API BaseObjectPool.isOpen()
> ---
>
> Key: POOL-190
> URL: https://issues.apache.org/jira/browse/POOL-190
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.6
> 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_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: 2.0
>
> Attachments: isOpen.diff
>
>
> Add API BaseObjectPool.isOpen()

--
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] (POOL-190) Add API BaseObjectPool.isOpen()

2011-11-14 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-190:
-

Issue Type: New Feature  (was: Bug)

> Add API BaseObjectPool.isOpen()
> ---
>
> Key: POOL-190
> URL: https://issues.apache.org/jira/browse/POOL-190
> Project: Commons Pool
>  Issue Type: New Feature
>Affects Versions: 1.5.6
> 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_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: 2.0
>
> Attachments: isOpen.diff
>
>
> Add API BaseObjectPool.isOpen()

--
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] (POOL-190) Add API BaseObjectPool.isOpen()

2011-11-13 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-190:
-

Fix Version/s: (was: 1.5.7)

Removing 1.5.7 as this is an API change.

> Add API BaseObjectPool.isOpen()
> ---
>
> Key: POOL-190
> URL: https://issues.apache.org/jira/browse/POOL-190
> Project: Commons Pool
>  Issue Type: New Feature
>Affects Versions: 1.5.6
> 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_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Fix For: 2.0
>
> Attachments: isOpen.diff
>
>
> Add API BaseObjectPool.isOpen()

--
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] (POOL-189) close() does not release threads blocked on borrowObject()

2011-11-13 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-189:
-

Fix Version/s: 1.5.7

Thanks for reporting this.

> close() does not release threads blocked on borrowObject()
> --
>
> Key: POOL-189
> URL: https://issues.apache.org/jira/browse/POOL-189
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.6
> Environment: java 1.6.0_24
>Reporter: Adrian Nistor
> Fix For: 1.5.7
>
> Attachments: Test.java
>
>
> Hi,
> When I call close() and borrowObject() concurrently with no objects in
> the pool, close() will finish but borrowObject() is blocked forever.
> The documentation of close() mentions that borrowObject() should fail 
> with IllegalStateException, so I would expect the waiting threads to 
> throw IllegalStateException.
> I will attach a test that exposes this problem. For this test, the 
> expected output is:
> 0
> 1
> 2
> ...
> 4999
> DONE
> But when the bug manifests (almost always for this test), the output 
> is:
> 0
> 1
> 2
> The test does not finish, it just gets stuck after printing several 
> values.
> Is this a bug or am I reading the documentation wrongly? Is there 
> a patch for this?
> Thanks!
> Adrian

--
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] (POOL-192) GenericKeyedObjectPool: clear() clears the keyed pool but does not decrease the item counter

2011-11-13 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/POOL-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated POOL-192:
-

Fix Version/s: 1.5.7

Thanks for reporting this.

> GenericKeyedObjectPool: clear() clears the keyed pool but does not decrease 
> the item counter
> 
>
> Key: POOL-192
> URL: https://issues.apache.org/jira/browse/POOL-192
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.6
>Reporter: Helge Dannenberg
> Fix For: 1.5.7
>
>
> If function 'clear(Object key)' in GenericKeyedObjectPool is called onto a 
> keyed pool, the ObjectQueue (= the keyed pool) is removed from the pool list. 
> Its items are deleteded in the function 'destroy()' afterwards. But as the 
> ObjectQueue is already removed, the itemcounter _totalInternalProcessing is 
> never decreased.
> As a result of this bug the pool exhausts even if the pool is empty.
> The solution is to decrease the counter _totalInternalProcessing in 
> 'destroy()' also if ObjectQueue in null.

--
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] (LANG-762) Handle or document ReflectionToStringBuilder and ToStringBuilder for collections that are not thread safe

2011-10-22 Thread Phil Steitz (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/LANG-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz updated LANG-762:
-

Attachment: ReflectionToStringBuilderConcurrencyTest.java

Attaching a test that illustrates the problem, which I don't think is solvable 
by the [lang] code (so probably this class should not be committed, as it will 
never pass).

The problem is that when you circumvent a class' internal synchronization to 
protect fields, all bets are off in terms of data integrity or CoMod 
exceptions. This should be clearly documented - i.e., users should be warned 
that this class should not be used in concurrent applications, or at least 
fields protected by synchronization should be excluded.

What is going on in the test case is that there are two different kinds of 
threads spawned concurrently - one kind uses the reflection back door opened by 
the builder to "inspect" an instance and the other kind mutates the instance 
using its synchronized methods.  Note that synchronizing the builder using the 
private field's monitor will not solve the problem (i.e., the first patch does 
not work) because what really needs to happen is that the access by the builder 
needs to be synchronized using the instance's monitor.  You could try to fix 
that by synchronizing on the instance, which would solve this example; but 
there is no guarantee that a class may not use its own internal locks, so there 
is no generic solution to this problem.

My recommendation is to just document the danger associated with using 
reflection to access private fields in the class javadoc.


> Handle or document ReflectionToStringBuilder and ToStringBuilder for 
> collections that are not thread safe
> -
>
> Key: LANG-762
> URL: https://issues.apache.org/jira/browse/LANG-762
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.builder.*
> 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_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
> Attachments: ReflectionToStringBuilderConcurrencyTest.java, 
> patch-LANG762.txt
>
>
> Moving discussion here from https://issues.apache.org/jira/browse/POOL-191 
> ConcurrentModificationException in GenericObjectPool LinkedList.
> It is possible to get a {{ConcurrentModificationException}} in a 
> {{LinkedList}} from a Commons Pool {{GenericObjectPool}}.
> This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a 
> subclass of {{GenericObjectPool}}. My guess is that it would happen with just 
> {{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have 
> anything to do with it I would venture.
> For example, in this stack trace {{JmsSessionPool}} is a subclass of 
> {{GenericObjectPool}}.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
> at java.util.LinkedList$ListItr.next(LinkedList.java:696)
> at java.util.AbstractCollection.toString(AbstractCollection.java:421)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuffer.append(StringBuffer.java:219)
> at 
> org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598)
> at 
> org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473)
> at 
> org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
> at 
> org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848)
> at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528)
> at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692)
> at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288)
> at 
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119)
> at 
> com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuffer.append(StringBuffer.java:219)
> at 
> org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586)
> at 
> org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550)
> at 
> org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436)
> at 
> org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848