[jira] [Commented] (MATH-1132) NaN transformation based on NaNStrategy
[ https://issues.apache.org/jira/browse/MATH-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045958#comment-14045958 ] Phil Steitz commented on MATH-1132: --- The right thing to do is to discuss ideas like this on the mailing list. NaN transformation based on NaNStrategy --- Key: MATH-1132 URL: https://issues.apache.org/jira/browse/MATH-1132 Project: Commons Math Issue Type: Improvement Affects Versions: 3.3 Reporter: Venkatesha Murthy TS Fix For: 3.4 Attachments: math-1132.patch The NaNs in a double array may need to be transformed to either +/- Infinity or removed before processing them(say such as in percentile). So basically from documenting angle; we will need to action as follows: Whenever a double quantity is a NaN (say in an array); based on the NanStrategy; it needs to be treated as follows before processing: a) MAXIMAL - replace with +infinity b) MINIMAL - replace with -Inifinity c) REMOVED - just remove it d) FIXED - Leave it as it is e) FAILED - throw a NaN exception Can this documentation be specifically added to NaNStrategy and perhaps a substitution value also can be added to enforce the documentation. In addition i will also submit a patch for a simple NaNTransformer implementation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1133) NaNStrategy for UnivariateStatistic and friends
[
https://issues.apache.org/jira/browse/MATH-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045983#comment-14045983
]
Phil Steitz commented on MATH-1133:
---
We should discuss on the mailing list. My inclination is to leave things as
they are. NaNStrategy exists because for rank transformations we *have* to do
something special for NaNs. In floating point computations, we have
traditionally just allowed NaNs to propagate.
NaNStrategy for UnivariateStatistic and friends
---
Key: MATH-1133
URL: https://issues.apache.org/jira/browse/MATH-1133
Project: Commons Math
Issue Type: Improvement
Reporter: Sergei Lebedev
Priority: Minor
In the current implementation univariate statistics don't allow to specify
NaN behaviour. For instance, the following code simply yields NaN as the
result.
{code:java}
Mean mean = new Mean();
mean.increment(42);
mean.increment(Double.NaN);
System.out.println(mean.getResult()); // prints 'NaN'.
{code}
Is it possible to parametrize all available statistics by NaNStrategy with
the default behaviour being a no-op?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MATH-1131) Kolmogorov-Smirnov Tests takes 'forever' on 10,000 item dataset
[ https://issues.apache.org/jira/browse/MATH-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043712#comment-14043712 ] Phil Steitz commented on MATH-1131: --- Thanks for reporting this and providing the code and data. I suspect the problem is in the matrix exponentiation done in the roundedK method. Anyone interested in patching this should start by looking at the reference in the class javadoc (and other sources) to identify optimizations that can be done for large samples. Kolmogorov-Smirnov Tests takes 'forever' on 10,000 item dataset --- Key: MATH-1131 URL: https://issues.apache.org/jira/browse/MATH-1131 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Java 8 Reporter: Schalk W. Cronjé Attachments: 1.txt, ReproduceKsIssue.groovy, ReproduceKsIssue.java I have code simplified to the following: KolmogorovSmirnovTest kst = new KolmogorovSmirnovTest(); NormalDistribution nd = new NormalDistribution(mean,stddev); kst.kolmogorovSmirnovTest(nd,dataset) I find that for my dataset of 10,000 items, the call to kolmogorovSmirnovTest takes 'forever'. It has not returned after nearly 15minutes and in one my my tests has gone over 150MB in memory usage. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-984) Incorrect (bugged) generating function getNextValue() in .random.EmpiricalDistribution
[ https://issues.apache.org/jira/browse/MATH-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-984. -- Resolution: Fixed Fixed in r1604639. Incorrect (bugged) generating function getNextValue() in .random.EmpiricalDistribution -- Key: MATH-984 URL: https://issues.apache.org/jira/browse/MATH-984 Project: Commons Math Issue Type: Bug Affects Versions: 3.2, 3.1.1 Environment: all Reporter: Radoslav Tsvetkov Assignee: Phil Steitz Fix For: 3.4 The generating function getNextValue() in org.apache.commons.math3.random.EmpiricalDistribution will generate wrong values for all Distributions that are single tailed or limited. For example Data which are resembling Exponential or Lognormal distributions. The problem could be easily seen in code and tested. In last version code ... 490 return getKernel(stats).sample(); ... it samples from Gaussian distribution to smooth in_the_bin. Obviously Gaussian Distribution is not limited and sometimes it does generates numbers outside the bin. In the case when it is the last bin it will generate wrong numbers. For example for empirical non-negative data it will generate negative rubbish. Additionally the proposed algorithm boldly returns only the mean value of the bin in case of one value! This last makes the generating function unusable for heavy tailed distributions with small number of values. (for example computer network traffic) On the last place usage of Gaussian soothing in the bin will change greatly some empirical distribution properties. The proposed method should be reworked to be applicable for real data which have often limited ranges. (either non-negative or both sides limited) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MATH-984) Incorrect (bugged) generating function getNextValue() in .random.EmpiricalDistribution
[ https://issues.apache.org/jira/browse/MATH-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-984: - Fix Version/s: 3.4 Incorrect (bugged) generating function getNextValue() in .random.EmpiricalDistribution -- Key: MATH-984 URL: https://issues.apache.org/jira/browse/MATH-984 Project: Commons Math Issue Type: Bug Affects Versions: 3.2, 3.1.1 Environment: all Reporter: Radoslav Tsvetkov Assignee: Phil Steitz Fix For: 3.4 The generating function getNextValue() in org.apache.commons.math3.random.EmpiricalDistribution will generate wrong values for all Distributions that are single tailed or limited. For example Data which are resembling Exponential or Lognormal distributions. The problem could be easily seen in code and tested. In last version code ... 490 return getKernel(stats).sample(); ... it samples from Gaussian distribution to smooth in_the_bin. Obviously Gaussian Distribution is not limited and sometimes it does generates numbers outside the bin. In the case when it is the last bin it will generate wrong numbers. For example for empirical non-negative data it will generate negative rubbish. Additionally the proposed algorithm boldly returns only the mean value of the bin in case of one value! This last makes the generating function unusable for heavy tailed distributions with small number of values. (for example computer network traffic) On the last place usage of Gaussian soothing in the bin will change greatly some empirical distribution properties. The proposed method should be reworked to be applicable for real data which have often limited ranges. (either non-negative or both sides limited) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved MATH-418. -- Resolution: Fixed Fix Version/s: (was: 4.0) 3.4 30-may patch with the following modifications committed in r 1604443: * Changed class names to PSquare to match references * Changed default quantile to 50 to be consistent with Percentile * Changed some hashcode implementations to use jdk Arrays.hashcode * Extracted constants to avoid repeated initialization (low, high marker indexes) * Changed random data tests to use a fixed seed * Miscellaneous javadoc edits Thanks for the patch! add a storeless version of Percentile - Key: MATH-418 URL: https://issues.apache.org/jira/browse/MATH-418 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Luc Maisonobe Fix For: 3.4 Attachments: 30-may-2014-418-psquare-patch, 418-psquare-patch, psquare-patch The Percentile class can handle only in-memory data. It would be interesting to use an on-line algorithm to estimate quantiles as a storeless statistic. An example of such an algorithm is the exponentially weighted stochastic approximation described in a 2000 paper by Fei Chen , Diane Lambert and José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which can be retrieved from CiteSeerX at [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14039461#comment-14039461 ] Phil Steitz commented on MATH-418: -- Sorry for delay. Working on this now... add a storeless version of Percentile - Key: MATH-418 URL: https://issues.apache.org/jira/browse/MATH-418 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Luc Maisonobe Fix For: 4.0 Attachments: 30-may-2014-418-psquare-patch, 418-psquare-patch, psquare-patch The Percentile class can handle only in-memory data. It would be interesting to use an on-line algorithm to estimate quantiles as a storeless statistic. An example of such an algorithm is the exponentially weighted stochastic approximation described in a 2000 paper by Fei Chen , Diane Lambert and José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which can be retrieved from CiteSeerX at [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015162#comment-14015162 ] Phil Steitz commented on MATH-418: -- The last patch looks good to me, modulo a few typos in the javadoc that I can fix in the commit and converting the random data generation to use a fixed seed (we like to do that to avoid random test failures). I will wait a day or two to see if there is other feedback; otherwise will commit. Thanks for the patch! add a storeless version of Percentile - Key: MATH-418 URL: https://issues.apache.org/jira/browse/MATH-418 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Luc Maisonobe Fix For: 4.0 Attachments: 30-may-2014-418-psquare-patch, 418-psquare-patch, psquare-patch The Percentile class can handle only in-memory data. It would be interesting to use an on-line algorithm to estimate quantiles as a storeless statistic. An example of such an algorithm is the exponentially weighted stochastic approximation described in a 2000 paper by Fei Chen , Diane Lambert and José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which can be retrieved from CiteSeerX at [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015167#comment-14015167 ] Phil Steitz commented on MATH-1120: --- The approach sounds reasonable to me, but the patch fails when I try to apply it to the code in trunk. It also appears to mix formatting changes with code modifications. Please turn off whatever your IDE is doing to reformat the code so we can focus on just what is being changed in the patch. Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 4.0 Attachments: excel-percentile-patch, percentile-with-estimation-patch Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (POOL-264) NullPointerException in GKOP.borrowObject()
[ https://issues.apache.org/jira/browse/POOL-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-264: - Affects Version/s: 1.5.7 1.6 Fix Version/s: 1.5.8 1.6.1 NullPointerException in GKOP.borrowObject() --- Key: POOL-264 URL: https://issues.apache.org/jira/browse/POOL-264 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6, 1.5.7, 1.6 Reporter: Leonid Meyerguz Fix For: 1.6.1, 1.5.8 While I cannot pin down a consistent repro, I occasionally observe a NullPointerException at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1126) The pool is configured as follows: maxActive = -1 maxIdle = 32 maxTotal = 32 whenExhaustedAction = WHEN_EXHAUSTED_GROW timeBetweenEvictionRunsMillis = 2 minEvictableIdleTimeMillis = 6 numTestsPerEvictionRun = -1 The NullPointerException is thrown in the WHEN_EXHAUSTED_GROW branch of the code. Specifically it appears that latch.getPool() returns null. Any suggestions for a work-around would be appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-417) BasicManagedDataSource does not free connection after transaction is commited
[
https://issues.apache.org/jira/browse/DBCP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-417.
BasicManagedDataSource does not free connection after transaction is commited
-
Key: DBCP-417
URL: https://issues.apache.org/jira/browse/DBCP-417
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Geronimo TM and JOTM, H2Database JDBC Driver
Reporter: Balazs Zsoldos
Priority: Blocker
Fix For: 2.0.1
Attachments: DBCP-417.patch, test-dbcp2-BasicManagedDataSource.zip
When a JTA Transaction is commited, the Managed connection is not available
again. The pool is becomes exhausted.
To reproduce:
{code:java}
Jotm jotm = new Jotm(true, false);
JdbcDataSource h2DataSource = new JdbcDataSource();
h2DataSource.setUrl(jdbc:h2:mem:test_mem);
BasicManagedDataSource basicManagedDataSource = new BasicManagedDataSource();
basicManagedDataSource.setTransactionManager(jotm.getTransactionManager());
basicManagedDataSource.setXaDataSourceInstance(h2DataSource);
basicManagedDataSource.setMaxTotal(2);
basicManagedDataSource.setMaxIdle(2);
UserTransaction userTransaction = jotm.getUserTransaction();
userTransaction.begin();
Connection connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
// The managed datasource will block here as there is no available connection
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
{code}
Set the priority to Blocker as BasicManagedDataSource cannot be used at all
with the bug.
Tested with Geronimo Transaction Manager and JOTM.
This worked well with version 1.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-349) Insert clob or blob with oracle connection crashes software
[ https://issues.apache.org/jira/browse/DBCP-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-349. Insert clob or blob with oracle connection crashes software Key: DBCP-349 URL: https://issues.apache.org/jira/browse/DBCP-349 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3 Environment: windows XP , JDK 1.6, oracle 10g, oracle driver 10.2.0.2 Reporter: alina joshi Priority: Critical Attachments: DBCP349.zip 1 tomcat 6.0.26 has tomcat-dbcp.jar that works completely fine. 2 tomcat 6.0.28, tomcat 6.0.29, tomcat 5.0.30, tomcat 5.0.31 has tomcat-dbcp.jar file that doesn't work and throws following error : java.lang.ClassCastException: org.apache.tomcat.dbcp.dbcp.PoolableConnection cannot be cast to oracle.jdbc.OracleConnection at oracle.sql.CLOB.createTemporary(CLOB.java:754) at oracle.sql.CLOB.createTemporary(CLOB.java:716) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Would like to know if there was any changes to the commons dbcp package for tomcat version 6.0.29? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
[ https://issues.apache.org/jira/browse/DBCP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-378. ManagedDataSource returns uses the same underlying DB connection across JTA tx -- Key: DBCP-378 URL: https://issues.apache.org/jira/browse/DBCP-378 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Ortwin Glück Priority: Critical It seems that when more than one JTA transaction is used within the same thread (suspend/resume transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions have no effect. The JTA semantics is violated this behaviour. Use the following code to setup a unit test that works in your environment // DS setup XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); ... TransactionManager tm = ... DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm, ods); AbandonedConfig ab = new AbandonedConfig(); ab.setLogAbandoned(false); ab.setRemoveAbandoned(true); ab.setRemoveAbandonedTimeout(15*60); connPool = new GenericObjectPool(null); // registers itself on the pool KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5); new PoolableManagedConnectionFactory(cf, connPool, stmtPool, null, 5, (CollectionString) null, // init sql false, // read-only false, // auto-commit Connection.TRANSACTION_READ_COMMITTED, (String) null, // catalog ab); ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); // Unit test tm.begin(); Connection c1 = source.getConnection(); Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); c1.close(); Transaction tx = tm.suspend(); tm.begin(); c2 = source.getConnection(); ic2 = ((ManagedConnection) c2).getInnermostDelegate(); c2.close(); assertNotSame(Pool must NOT use identical connection across tx, ic1, ic2); tm.commit(); tm.resume(tx); tm.commit(); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-383) NPE during XA commit (possibly doing startup recovery)
[ https://issues.apache.org/jira/browse/DBCP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-383. NPE during XA commit (possibly doing startup recovery) -- Key: DBCP-383 URL: https://issues.apache.org/jira/browse/DBCP-383 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Martin Lichtin Encountering nullpointer exception at java.lang.NullPointerException at org.apache.commons.dbcp.managed.LocalXAConnectionFactory$LocalXAResource.commit(LocalXAConnectionFactory.java:201) at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:784) at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:73) at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:111) at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:87) at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Propagator.java:66) at com.atomikos.icatch.imp.HeurHazardStateHandler.onTimeout(HeurHazardStateHandler.java:120) at com.atomikos.icatch.imp.CoordinatorImp.alarm(CoordinatorImp.java:1105) at com.atomikos.timing.PooledAlarmTimer.notifyListeners(PooledAlarmTimer.java:112) at com.atomikos.timing.PooledAlarmTimer.run(PooledAlarmTimer.java:99) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-400) The documentation of maxOpenPreparedStatements parameter seems to be wrong
[
https://issues.apache.org/jira/browse/DBCP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-400.
The documentation of maxOpenPreparedStatements parameter seems to be wrong
--
Key: DBCP-400
URL: https://issues.apache.org/jira/browse/DBCP-400
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4, 1.4.1
Reporter: Gábor Lipták
Labels: limit, pool
Fix For: 1.5.1, 2.0
We had earlier a datasource, which had no maxOpenPreparedStatements property
defined. Something like this:
{code:xml}
bean id=basicDataSource class=org.apache.commons.dbcp.BasicDataSource
init-method=createDataSource destroy-method=close
property name=poolPreparedStatements value=true /
property name=url value=${datasource.url} /
property name=driverClassName
value=${datasource.driverClassName} /
property name=username value=${datasource.username} /
property name=password value=${datasource.password} /
property name=initialSize value=${datasource.initialSize}
/
property name=maxActive value=${datasource.maxActive} /
property name=maxIdle value=${datasource.maxIdle} /
property name=minIdle value=${datasource.minIdle} /
property name=timeBetweenEvictionRunsMillis
value=${datasource.timeBetweenEvictionRunsMillis} /
property name=minEvictableIdleTimeMillis
value=${datasource.minEvictableIdleTimeMillis} /
property name=maxWait value=${datasource.maxWait} /
/bean
{code}
Then we wanted to have a parameter to limit the prepared statement pool, so
we added a new line for the maxOpenPreparedStatements (for compatibility
reasons we added the line with a config file having '0' value which should
mean unlimited according to the documentation at
http://commons.apache.org/proper/commons-dbcp/configuration.html):
{code:xml}
bean id=basicDataSource class=org.apache.commons.dbcp.BasicDataSource
init-method=createDataSource destroy-method=close
property name=poolPreparedStatements value=true /
property name=maxOpenPreparedStatements
value=${datasource.maxOpenPreparedStatements} /
property name=url value=${datasource.url} /
property name=driverClassName
value=${datasource.driverClassName} /
property name=username value=${datasource.username} /
property name=password value=${datasource.password} /
property name=initialSize value=${datasource.initialSize}
/
property name=maxActive value=${datasource.maxActive} /
property name=maxIdle value=${datasource.maxIdle} /
property name=minIdle value=${datasource.minIdle} /
property name=timeBetweenEvictionRunsMillis
value=${datasource.timeBetweenEvictionRunsMillis} /
property name=minEvictableIdleTimeMillis
value=${datasource.minEvictableIdleTimeMillis} /
property name=maxWait value=${datasource.maxWait} /
/bean
{code}
We ended up in having the following exception:
{noformat}
Caused by: java.sql.SQLException: MaxOpenPreparedStatements limit reached
at
org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:109)
at
org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:281)
at
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
...
[:1.7.0_07]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_07]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_07]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_07]
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
at
org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)
at
org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at
org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at
[jira] [Closed] (DBCP-399) Rollback on PoolableConnectionFactory.passivateObject() has to be configuration controlled.
[ https://issues.apache.org/jira/browse/DBCP-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-399. Rollback on PoolableConnectionFactory.passivateObject() has to be configuration controlled. --- Key: DBCP-399 URL: https://issues.apache.org/jira/browse/DBCP-399 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Environment: Any databases, especially on those, where the rollback calls are costly. Reporter: Girish Adat Labels: easyfix, performance In certain databases like IBM DB2, the rollback calls are costly. Also, on any database, this avoids an unnecessary call to DB upon returning a connection back to pool, and thus enhances the application performance. So it would be good, if there is an optional configuration parameter that controls the rollbackAsCleanUpAction behaviour. This can be made false (can be true by default, aiming current users) if the application can guarantee itself that, no connection is returned to the pool without an explicit call to commit() or rollback(), even in the case of a non-readonly and non-autocommit connection. A few more bits: This caused a 1/11, i.e. approx 10% performance loss in our application. Hence making this a bug (a performance issue), and not a Feature Request / Improvement! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-402) Add a way to set an instance of java.sql.Driver directly on org.apache.commons.dbcp2.BasicDataSource
[ https://issues.apache.org/jira/browse/DBCP-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-402. Add a way to set an instance of java.sql.Driver directly on org.apache.commons.dbcp2.BasicDataSource Key: DBCP-402 URL: https://issues.apache.org/jira/browse/DBCP-402 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 2.0 Reporter: Ben Hale Fix For: 2.0 Currently when org.apache.commons.dbcp2.BasicDataSource is directly instantiated (e.g. in an IoC environment), the only way to set the type of java.sql.Driver that is should use is by passing in a String classname which is then passed to DriverManager. The downside to this is that it requires the DataSource and the Driver to be in the same classloader. In practice many times the Driver is in the application classloader while the DataSource is in the container classloader meaning that other than packaging a Tomcat JAR in your application you cannot use the DataSource directly. It'd be great to have a way to pass the actual instance of Driver to the DataSource and have it use that instead of going to DriverManager to find it. This would enable standard classloader inheritance to work properly and allow the non-adjacent packaging of the Driver and DataSource. An example of this style of configuration can be found in Spring's SimpleDriverDataSource[1]. [1]: http://docs.spring.io/spring/docs/3.2.x/javadoc-api/org/springframework/jdbc/datasource/SimpleDriverDataSource.html#setDriver(java.sql.Driver) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-404) Mutable fields should be private
[ https://issues.apache.org/jira/browse/DBCP-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-404. Mutable fields should be private Key: DBCP-404 URL: https://issues.apache.org/jira/browse/DBCP-404 Project: Commons Dbcp Issue Type: Bug Reporter: Sebb Fix For: 2.0 Non-private mutable fields make thread-safety harder. Make all mutable fields private (or at worst package-protected), and use getters/setters for access if necessary. This allows synchronisation to be easily added later if necessary, as well as potentially allowing validation of values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-380) DelegatingConnection isWrapperFor dies on older JDBC drivers
[ https://issues.apache.org/jira/browse/DBCP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-380. DelegatingConnection isWrapperFor dies on older JDBC drivers Key: DBCP-380 URL: https://issues.apache.org/jira/browse/DBCP-380 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Balazs Zsoldos Fix For: 1.3.1, 1.4.1, 1.5.1, 2.0 Attachments: DelegatingConnection.java.patch Original Estimate: 1h Remaining Estimate: 1h The isWrapperFor function simply calls towards to the delegated connection iswrappedfor function instead of checking the result first by hand like in the unwrap function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-373) Ability to configure upper bound on total number of connections managed by pooled data sources across all keys (user/password).
[ https://issues.apache.org/jira/browse/DBCP-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-373. 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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-375) initialSize minIdle = non-performing query plans are chosen
[ https://issues.apache.org/jira/browse/DBCP-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-375. initialSize minIdle = non-performing query plans are chosen -- Key: DBCP-375 URL: https://issues.apache.org/jira/browse/DBCP-375 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1, 1.2.2, 1.3, 1.4 Environment: * dhcp 1.2.1, pool 1.2 (issue also tested with latests library version = still there) * java 6 * oracle 10.2 and 11 (ojdbc 4 - 6) * hibernate 2.1.8 Reporter: Patrick Hammer We found a strange behaviour when setting initialSize=0 and minIdle=10: * non-performing query plans are used on the DB * correct query plans are used by small java app without dhcp and pool (or by sqldeveloper) Analysis: * DB tracing showed no difference between the inputs of performing/non-performing queries * ojdbc tracing showed no difference neither Work-around: * set initialSize = minIdle, e.g., both to 10. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-369) Exception when using SharedPoolDataSource concurrently
[
https://issues.apache.org/jira/browse/DBCP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-369.
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.5.1, 2.0
Attachments: DBCP-369.patch
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 ArrayListSharedPoolDataSource dataSources = new
ArrayListSharedPoolDataSource();
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 was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-382) Could not set flag accessToUnderlyingConnectionAllowed in context.xml for DriverAdapterCPDS/PerUserPoolDataSource
[
https://issues.apache.org/jira/browse/DBCP-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-382.
Could not set flag accessToUnderlyingConnectionAllowed in context.xml for
DriverAdapterCPDS/PerUserPoolDataSource
-
Key: DBCP-382
URL: https://issues.apache.org/jira/browse/DBCP-382
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.3
Environment: Apache Tomcat 6.0.32 / DBCP 1.3
Reporter: Stefan Rempfer
Fix For: 1.5.1, 2.0
Could not set flag accessToUnderlyingConnectionAllowed in context.xml for
DriverAdapterCPDS/PerUserPoolDataSource because the property is not
considered from the factory.
A possible solution is to add following lines to class DriverAdapterCPDS on
the end of method getObjectInstance
{code}
ra = ref.get(accessToUnderlyingConnectionAllowed);
if (ra != null ra.getContent() != null) {
setAccessToUnderlyingConnectionAllowed(Boolean.valueOf(ra.getContent().toString()).booleanValue());
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-389) Provide a configurable implementation of OSGi 4.2 DataSourceFactory
[ https://issues.apache.org/jira/browse/DBCP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-389. Provide a configurable implementation of OSGi 4.2 DataSourceFactory --- Key: DBCP-389 URL: https://issues.apache.org/jira/browse/DBCP-389 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4 Environment: Any OSGi 4.2 environment like Felix. Reporter: Matt Bishop Using JDBC Drivers in OSGi has been made more understandable in R4.2 with the addition of the DataSourceFactory service interface. It makes it pretty easy to consume JDBC datasources in OSGi. However, no one implements this interface in a driver-agnostic manner. DBCP is well-positioned to provide a configurable DataSourceFactory that could provide the DataSource variants to services. More information can be found here: http://www.osgi.org/javadoc/r4v42/org/osgi/service/jdbc/DataSourceFactory.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-390) calling invalidObject(badConnection) damage the counting of the objects in the pool.
[ https://issues.apache.org/jira/browse/DBCP-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-390. calling invalidObject(badConnection) damage the counting of the objects in the pool. - Key: DBCP-390 URL: https://issues.apache.org/jira/browse/DBCP-390 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Environment: All env Reporter: neng xu We are using DBCP pool. The pattern of using DBCP pool is same as Apache DBCP pool example PoolingDataSourceDataSourceExample.java. When cleaning bad connections, I noticed that it called pool.invalidObject(object) method to clean the bad connection object from the pool. Recently we found that calling invalidObject(object) could damage the number of active connections of the pool because this method always silently reduce the number regardless the objects was removed from pool or not. For example, when the connection object is null (creating database connection timeout happens), calling invalidObject(badConnection) would cause the number of Active connections to be reduce one even the method did not remove any object from pool. This damage the counting of the object in the pool. This method should only reduce the number of the objects in the pool when it successfully removed an object from the pool. Note: I understand that we may resolve the problem by checking object is null (or object is in pool) before calling invalidObject() method. But I think it is just a first-aid solution. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-350) Problem with DBCP 1.3 /jdk 6 and oracle spatial
[ https://issues.apache.org/jira/browse/DBCP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-350. Problem with DBCP 1.3 /jdk 6 and oracle spatial --- Key: DBCP-350 URL: https://issues.apache.org/jira/browse/DBCP-350 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar Reporter: Nils Hildebrand Fix For: 1.3.1, 1.4.1 We have a GIS-application running on Tomcat 5.5. As webserver we are using Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp). The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31. After the upgrade we get - in certain situations a: java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. After looking through the Tomcat 5.5 changelogs we stumbled across a change made in 5.5.30: Upgrade to DBCP 1.3. I can affirm now that the problem is gone when downgrading to DBCP 1.2.2. The same problem occurs when using DBCP 1.4. It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3 I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-366) Getting Exception when trying to get the PrepareStatement from Connection From DBCP Pool
[
https://issues.apache.org/jira/browse/DBCP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-366.
Getting Exception when trying to get the PrepareStatement from Connection
From DBCP Pool
Key: DBCP-366
URL: https://issues.apache.org/jira/browse/DBCP-366
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.2
Environment: Linux machine
Reporter: saroj kumar balusu
Original Estimate: 24h
Remaining Estimate: 24h
Using commons-dbcp-1.2.2.jar version with Tomcat version 6.0.29.
Getting the following exception when trying to get the
java.sql.PrepareStatement using a Connection from DBCP Pool:
{noformat}
java.sql.SQLException: Connection is closed.
at
org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.checkOpen(PoolingDriver.java:263)
at
org.apache.commons.dbcp.PoolingDriver$PoolGuardConnectionWrapper.prepareStatement(PoolingDriver.java:366)
{noformat}
This is the configuration we are using for creating Connection Pool from DBCP:
{code:java}
public static void setupDriver(String connectURI, String userName,
String dbPassword, String maxActive, String minIdle,
String maxWait, String poolName) throws Exception {
GenericObjectPool.Config config = new
GenericObjectPool.Config();
config.maxActive = Integer.parseInt(maxActive);
config.minIdle = Integer.parseInt(minIdle);
config.maxWait = Integer.parseInt(maxWait);
config.whenExhaustedAction = 2;
config.minEvictableIdleTimeMillis = 180;
config.timeBetweenEvictionRunsMillis = 180;
config.numTestsPerEvictionRun = 3;
config.testOnBorrow = true;
config.testOnReturn = true;
config.testWhileIdle = true;
ObjectPool connectionPool = new GenericObjectPool(null, config);
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(
connectURI, userName, dbPassword);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(
connectionFactory, connectionPool, null, null,
false, true);
poolableConnectionFactory.setValidationQuery(select 1 from
dual);
driver = new PoolingDriver();
driver.registerPool(poolName, connectionPool);
driver.setAccessToUnderlyingConnectionAllowed(true);
// PoolingDataSource dataSource = new
PoolingDataSource(connectionPool);
// return dataSource;
}
{code}
The following code is used to get the Connection:
{code:java}
public java.sql.Connection getConnection(poolName) {
Connection con =
DriverManager.getConnection(jdbc:apache:commons:dbcp:+poolName);
return con;
}
{code}
The following code is used to release the connection:
{code:java}
public void release(Connection conn) throws DBException {
try {
conn.close();
} catch (Exception e) {
throw new Exception(e.getMessage(), e);
}
}
{code}
Can you let us know what might be the exact reason for the following
exception?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-351) setAutoCommit called too many times
[
https://issues.apache.org/jira/browse/DBCP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-351.
setAutoCommit called too many times
---
Key: DBCP-351
URL: https://issues.apache.org/jira/browse/DBCP-351
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4
Reporter: OD
Fix For: 2.0
passivateObject in PoolableConnectionFactory sets autoCommit to true, even if
defaultAutoCommit is set to false. This results in two extra db queries for
every use of the connection (set false, do work, set true). This creates a
significant amount of overhead, even if the connection is never even used.
I propose it be changed to:
if(conn.getAutoCommit() != _defaultAutoCommit)
{
conn.setAutoCommit(_defaultAutoCommit);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-363) dbcp bundle should use DynamicImport
[ https://issues.apache.org/jira/browse/DBCP-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-363. 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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-361) BasicManagedDataSource optional transaction enlistment
[ https://issues.apache.org/jira/browse/DBCP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-361. 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 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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-365) StackOverflowError SharedPoolDataSource.getPooledConnectionAndInfo() Postgresql
[ https://issues.apache.org/jira/browse/DBCP-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-365. StackOverflowError SharedPoolDataSource.getPooledConnectionAndInfo() Postgresql --- Key: DBCP-365 URL: https://issues.apache.org/jira/browse/DBCP-365 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Environment: Windows XP 64-bit multi-threaded Reporter: Axl Labels: JDBC, postgresql This might be a problem with the JDBC driver for PostgreSQL 9.1 but it also shows up here. Since this is a StackOverflowError there isn't much information about what specifically is causing this. I'm guessing it's a Class.forName() for one of the org.postgresql.* classes but not sure which one. The Class.forName() goes into a loop which throws the StackOverflowError. SharedPoolDataSource.getPooledConnectionAndInfo(String, String) line: 174 SharedPoolDataSource(InstanceKeyDataSource).getConnection(String, String) line: 701 SharedPoolDataSource(InstanceKeyDataSource).getConnection() line: 676 spds = new org.apache.commons.dbcp.datasources.SharedPoolDataSource(); cpds = new org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS(); cpds.setDriver(org.postgresql.Driver); cpds.setUrl(jdbc:postgresql://localhost:1234/mydatabasename); cpds.setUser(myuser); cpds.setPassword(mypass); spds.setConnectionPoolDataSource(cpds); spds.setMaxActive(30); spds.setMaxWait(50); conn = spds.getConnection(); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-368) determine which connections to hold in pool by relative value
[ https://issues.apache.org/jira/browse/DBCP-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-368. 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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-219) how to kill a connection from the connection pool without shutting down the connection pool
[ https://issues.apache.org/jira/browse/DBCP-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-219. how to kill a connection from the connection pool without shutting down the connection pool --- Key: DBCP-219 URL: https://issues.apache.org/jira/browse/DBCP-219 Project: Commons Dbcp Issue Type: New Feature Affects Versions: 2.0 Environment: Windows, Unix Reporter: Bill Liu Fix For: 2.0 Hi: This is really not a bug but probably a desired feature and something I am not aware of. We use the Apache connection pool in a Servlet environment. We need the feature to kill or close a connection forcefully when it is being used by a servlet. The reason can be various: an evil servlet that holds a connection forever, db issue, network issue, etc. How can we do that? I notice that datasource.getConnection() always returns a new connection. How do we keep track of connections that are being used so we can close them if needed? Currently we can only kill one at the database side by a DBA. Should we write a a util to keep track of connection objects that are borrowed by clients? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-246) Logging For DBCP
[ https://issues.apache.org/jira/browse/DBCP-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-246. Logging For DBCP Key: DBCP-246 URL: https://issues.apache.org/jira/browse/DBCP-246 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2.2 Environment: Java DBCP Reporter: Madhusudan Pagadala Fix For: 2.0 Hi, I work in Operations, I feel that adding debug and info statements for this commons-dbcp is very much helpful to debug the database connection problems in production environment to the applications, its very useful for tuning the connectioon pool parameters also, I got surprised how the logging is missing to DBCP packages. Can I expect this to add in near releases. Thanks, Madhu. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-357) Connection validationQuery mechanism should be replaced by new method connection#isValid()
[ https://issues.apache.org/jira/browse/DBCP-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-357. Connection validationQuery mechanism should be replaced by new method connection#isValid() -- Key: DBCP-357 URL: https://issues.apache.org/jira/browse/DBCP-357 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.4, 1.4.1 Reporter: Philippe Mouawad Labels: PERFORMANCE Fix For: 2.0 Hello, Current method of connection validation relies on validationQuery. This method has a rather big performance impact on the DB (CPU, for example 3% with SELECT 1 FROM DUAL even with Oracle 10G FAST DUAL) and make an additional query for each borrow (when testOnBorrow is true). Wouldn't it be better to use new JDBC 4 method isValid which relies on Driver check ? (Oracle would for example use its internal method ping) Thank you Philippe http://www.ubik-ingenierie.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-353) When DB Restarts(Bounce) the number ESTABLISHED DB connections exceeds its maximum configured limit.
[ https://issues.apache.org/jira/browse/DBCP-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-353. When DB Restarts(Bounce) the number ESTABLISHED DB connections exceeds its maximum configured limit. Key: DBCP-353 URL: https://issues.apache.org/jira/browse/DBCP-353 Project: Commons Dbcp Issue Type: Bug Reporter: Radhika Zawar Fix For: 1.3.1, 1.4.1 We have set Max connections configuration to 100. There was heavy load on application. When we restarted DB in between, number of connections exceeds from 100 to 200,250... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-355) DataSourceXAConnectionFactory does not store the XAConnection
[
https://issues.apache.org/jira/browse/DBCP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-355.
DataSourceXAConnectionFactory does not store the XAConnection
-
Key: DBCP-355
URL: https://issues.apache.org/jira/browse/DBCP-355
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.3, 1.4
Environment: MysqlXADataSource passed to BasicManagedDataSource
Reporter: Clement Pang
Fix For: 1.5.1, 2.0
Attachments: DBCP-355.diff
We have been diagnosing a leak with DBCP and XA mySQL and discovered that the
mySQL driver expects close() to be invoked on the XAConnection obtained from
xaDataSource.getXAConnection() instead of the java.sql.Connection returned by
xaConnection.getConnection();
The following code snippet in DataSourceXAConnectionFactory illustrates how
the XAConnection is lost:
public Connection createConnection() throws SQLException {
// create a new XAConection
XAConnection xaConnection;
if (username == null) {
xaConnection = xaDataSource.getXAConnection();
} else {
xaConnection = xaDataSource.getXAConnection(username, password);
}
// get the real connection and XAResource from the connection
Connection connection = xaConnection.getConnection();
XAResource xaResource = xaConnection.getXAResource();
// register the xa resource for the connection
transactionRegistry.registerConnection(connection, xaResource);
return connection;
}
In the code snippet above, the XAConnection is basically discarded after
using it to obtain the java.sql.Connection and XAResource. It would be ideal
if it actually associates the XAConnection in the transactionRegistry as well
so that when PooledManagedConnection handles reallyClose(), it can also
invoke close() on the XAConnection by interrogating the TransactionRegistry
for the actual XAConnection to close.
This may be something that's mySQL specific.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-379) number of connections created has crossed more than maxActive
[ https://issues.apache.org/jira/browse/DBCP-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-379. number of connections created has crossed more than maxActive -- Key: DBCP-379 URL: https://issues.apache.org/jira/browse/DBCP-379 Project: Commons Dbcp Issue Type: Bug Environment: OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 2) uname:Linux 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 vm_info: Java HotSpot(TM) Server VM (1.4.2_13-b06) for linux-x86, built on Oct 18 2006 09:55:11 by unknown with unknown compiler Reporter: Bhaskar NA Fix For: 1.5.1, 2.0 I found that when the minIdle is configured then during loads, common pool creates more number of connections it will be greater than maxActive. When I had following settings: maxActive = 50 maxIdle = 30 minIdle=30 factory=org.apache.commons.dbcp.BasicDataSourceFactory maxWait=1 timeBetweenEvictionRunsMillis=90 numTestsPerEvictionRun=50 minEvictableIdleTimeMillis=180 testWhileIdle=true testOnBorrow = true validationQuery='select 1 from dual' Number of connections in the pool went upto 121. (found thru netstat) When I changed minIdle to 15 and did my load test connecitons in the pool went upto 66 Looks like maxActive is getting bypassed with minIdle. When I changed minIdle to 10 and maxActive to 30 and maxIdle to 30 then number of connections went upto 40. Can someone please throw light on what is going on here? I am using DBCP 1.2.1 and common pool 1.3. Bhaskar -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-223) Auto-alert of connection pool critical events?
[ https://issues.apache.org/jira/browse/DBCP-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-223. Auto-alert of connection pool critical events? -- Key: DBCP-223 URL: https://issues.apache.org/jira/browse/DBCP-223 Project: Commons Dbcp Issue Type: New Feature Affects Versions: 1.2.2 Environment: Windows, Unix Reporter: Bill Liu Fix For: 2.0 Is there a way that the DBCP automatically alerts critical events such as db down or max # of connections reached too frequently? I was wondering if there's something written or this should be a nice feature for the DBCP. Our ops team really need to be alerted right away if the DBCP has some critical events. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-354) released dbcp 1.0 pom is broken
[ https://issues.apache.org/jira/browse/DBCP-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-354. released dbcp 1.0 pom is broken --- Key: DBCP-354 URL: https://issues.apache.org/jira/browse/DBCP-354 Project: Commons Dbcp Issue Type: Bug Reporter: Jeff Hodges The pom file for dbcp 1.0 contains the version 1.0-dev, breaking dependency resolution for jars (like naming-config 0.8) that depend on it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-229) Track callers of active connections for debugging
[ https://issues.apache.org/jira/browse/DBCP-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-229. Track callers of active connections for debugging - Key: DBCP-229 URL: https://issues.apache.org/jira/browse/DBCP-229 Project: Commons Dbcp Issue Type: New Feature Reporter: Armin Häberling Fix For: 2.0 Lately we got the following exception org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) The reason for that was that some piece of code opened a connection, but never closed it. Tracking the active connections (and the callers of the getConnection method) would it make it easier to find such erroneous code. One possible approach would be to add the connection returned by BasicDataSource.getConnection together with the stacktrace in a Map holding all active connections. And removing the connection from the map during PoolableDataSource.close(). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-358) Equals implementations in DelegatingXxx classes are not symmetric
[ https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-358. Equals implementations in DelegatingXxx classes are not symmetric - Key: DBCP-358 URL: https://issues.apache.org/jira/browse/DBCP-358 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2, 1.2.2, 1.3, 1.4 Reporter: Phil Steitz Fix For: 2.0 For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - wrapper.equals(delegate) returns true, but delegate.equals(wrapper) will in general return false. I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-356) ManagedDataSource doesn't work with an active transaction in progress on IBM JDK 6+
[ https://issues.apache.org/jira/browse/DBCP-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-356. ManagedDataSource doesn't work with an active transaction in progress on IBM JDK 6+ --- Key: DBCP-356 URL: https://issues.apache.org/jira/browse/DBCP-356 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3, 1.4 Environment: IBM JDK 6 java version 1.6.0 Java(TM) SE Runtime Environment (build pwa6460sr9fp1-20110208_03(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows 7 amd64-64 jvmwa6460sr9-20110203_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 commons-dbcp of version 1.3 / 1.4 Reporter: an envy guest Labels: ibm, xaresource Fix For: 1.3.1, 1.4.1 Attachments: TransactionRegistry.java.patch, TransactionRegistry.java.patch, commons-dbcp-TransactionRegistry.diff When using IBM JDK 6+ and trying to build commons-dbcp, these tests fail: org.apache.commons.dbcp.managed.TestBasicManagedDataSource org.apache.commons.dbcp.managed.TestManagedDataSourceInTx with error: java.sql.SQLException: Connection does not have a registered XAResource null, UserName=null, null at org.apache.commons.dbcp.managed.TransactionRegistry.getXAResource(TransactionRegistry.java:81) at org.apache.commons.dbcp.managed.TransactionContext.setSharedConnection(TransactionContext.java:88) at org.apache.commons.dbcp.managed.ManagedConnection.updateTransactionStatus(ManagedConnection.java:131) at org.apache.commons.dbcp.managed.ManagedConnection.init(ManagedConnection.java:55) at org.apache.commons.dbcp.managed.ManagedDataSource.getConnection(ManagedDataSource.java:76) at org.apache.commons.dbcp.managed.TestManagedDataSource.getConnection(TestManagedDataSource.java:53) at org.apache.commons.dbcp.TestConnectionPool.newConnection(TestConnectionPool.java:81) at org.apache.commons.dbcp.managed.TestManagedDataSourceInTx.testMaxActive(TestManagedDataSourceInTx.java:102) When used in conjunction with OpenEJB 3.1.4 examples, the error is the same. The problem disappears when switched to Oracle JDK 1.6.24 (so, all tests are passed and OpenEJB examples are working). I beleive this has something to do with differences in java.lang.ref.WeakReference implementations between IBM and Oracle JDKs, which was already discussed here: http://www.mail-archive.com/dev@commons.apache.org/msg13107.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-261) How can I use custom object pool?
[ https://issues.apache.org/jira/browse/DBCP-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-261. How can I use custom object pool? - Key: DBCP-261 URL: https://issues.apache.org/jira/browse/DBCP-261 Project: Commons Dbcp Issue Type: New Feature Reporter: Navis Fix For: 2.0 need some injection point of custom implementation replacing pathetically inefficient org.apache.commons.pool.impl.GenericObjectPool. thanks -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-322) CPDSConnectionFactory.validateObject(Object) ignores Throwable
[
https://issues.apache.org/jira/browse/DBCP-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-322.
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 was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-249) Validate connection only on create.
[ https://issues.apache.org/jira/browse/DBCP-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-249. Validate connection only on create. --- Key: DBCP-249 URL: https://issues.apache.org/jira/browse/DBCP-249 Project: Commons Dbcp Issue Type: New Feature Affects Versions: 1.2.2 Environment: All. Reporter: Parag Mehta Fix For: 2.0 Request to add support for testOnCreate, to validate connections only when they are created, much less frequent than on borrow. This will solve issues where for example driver logs you into master instead of db on the connection string because db is not available (e.g. Sybase) and then rest of the queries fail. This only happens on first login. Hence validating the correct db using sql can test such a case so that borrowers are guaranteed correct db without having to testOnBorrow every time. May also be worthwhile to support different validation queries for testing at different times. Thanks. Parag -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-297) Ciphered passwords
[ https://issues.apache.org/jira/browse/DBCP-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-297. Ciphered passwords -- Key: DBCP-297 URL: https://issues.apache.org/jira/browse/DBCP-297 Project: Commons Dbcp Issue Type: New Feature Environment: All Reporter: Jean-Louis MONTEIRO Fix For: 2.0 Attachments: patch-dbcp-297.txt It would be nice to allow ciphered passwords with pluggable codec mechanisms. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-319) Make private fields final where possible
[ https://issues.apache.org/jira/browse/DBCP-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-319. 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 was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-347) DelegatingStatement class has incomplete isWrapperFor method
[
https://issues.apache.org/jira/browse/DBCP-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-347.
DelegatingStatement class has incomplete isWrapperFor method
Key: DBCP-347
URL: https://issues.apache.org/jira/browse/DBCP-347
Project: Commons Dbcp
Issue Type: Bug
Environment: Windows 7. java version 1.6.0_21. Dell Latitude E6410.
Reporter: Robert Poskrobek
Fix For: 1.3.1, 1.4.1, 1.5.1, 2.0
Original Estimate: 1h
Remaining Estimate: 1h
Currently org.apache.commons.dbcp.DelegatingStatement#isWrapperFor checks
only if:
1. Requested class is assignable from the DelegatingStatement instance:
iface.isAssignableFrom(getClass())
2. Wrapped object is a wrapper for the requested class:
_stmt.isWrapperFor(iface)
I think there should be another option checked i.e. requested class is
assignable from the wrapped object's class. For example:
iface.isAssignableFrom(_stmt.getClass())
This is especially that in fact unwrap method properly assumes this
possiblity i.e.: return iface.cast(_stmt);
The whole method should be:
public boolean isWrapperFor(Class? iface) throws SQLException {
return iface.isAssignableFrom(getClass()) ||
iface.isAssignableFrom(_stmt.getClass()) || _stmt.isWrapperFor(iface);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (DBCP-300) remove synchronize access of createDataSource
[ https://issues.apache.org/jira/browse/DBCP-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-300. remove synchronize access of createDataSource - Key: DBCP-300 URL: https://issues.apache.org/jira/browse/DBCP-300 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2.2, 1.3, 1.4 Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2 Reporter: Nikhil Singh Fix For: 2.0 For JDK1.5 onwards we can make the DataSource volatile and start using double checked locking idiom. In my performance testing I have already started seeing wait time on this lock. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (POOL-259) Client wait time is not updated when max wait is configured to be unlimited
[ https://issues.apache.org/jira/browse/POOL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved POOL-259. -- Resolution: Fixed Fix Version/s: 2.3 Fixed in r1595711. Client wait time is not updated when max wait is configured to be unlimited --- Key: POOL-259 URL: https://issues.apache.org/jira/browse/POOL-259 Project: Commons Pool Issue Type: Bug Affects Versions: 2.2 Reporter: Phil Steitz Fix For: 2.3 The local variable waitTime used by borrowObject in both GOP and GKOP is not updated unless borrowMaxWaitMillis is non-negative and blockWhenExhausted is true. This effectively zeros the JMX client wait time properties for these configurations. Even when there is a maxWait configured and the pool is set to block when exhausted, what ends up being reported is only the wait time on the instance queue. Note that this bug is JMX reporting only. I am inclined to fix this by setting waitTime at the beginning and updating it at the end (including activate and validate times). We should also add test cases for this and the other stats exposed via JMX. Patches welcome, as it may take me a little while to get to this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-419) Thread got locked while getting connection for MSSQLServer 2008DB
[ https://issues.apache.org/jira/browse/DBCP-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-419. Resolution: Invalid This looks like normal behavior to me. This appears to be part of a thread dump showing one thread holding a lock. Please use the Commons User list to ask usage questions. If you can demonstrate a deadlock or other actual bug, feel free to reopen. Also, it would be a good idea to upgrade to a less ancient version of DBCP. Thread got locked while getting connection for MSSQLServer 2008DB - Key: DBCP-419 URL: https://issues.apache.org/jira/browse/DBCP-419 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Environment: AIX, JDK1.7 Reporter: Santhosh Daida Priority: Blocker Below exception was seen in getting connection for MSSQLServer 2008 pool-3-thread-17 prio=10 tid=0x2aaac0158000 nid=0x4cb7 in Object.wait() [0x43d77000] java.lang.Thread.State: RUNNABLE at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1130) - locked 0x00078002b498 (a org.apache.commons.dbcp.BasicDataSource) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) My application needs only one connection for every 60 seconds and I am using default properties of BasicDataSource. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DBCP-418) Cannot Disable JMX
[ https://issues.apache.org/jira/browse/DBCP-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved DBCP-418. -- Resolution: Fixed Patch committed in r1594068. Cannot Disable JMX -- Key: DBCP-418 URL: https://issues.apache.org/jira/browse/DBCP-418 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: Google App Engine Reporter: William R. Speirs Fix For: 2.0.1 Attachments: DBCP-418.patch There is no way to disable the use of JMX when using PoolableConnections. Line 48 of PoolableConnection.java uses the ManagementFactory which is blacklisted in Google App Engine. private static MBeanServer MBEAN_SERVER = ManagementFactory.getPlatformMBeanServer(); There should be a way to disable all JMX bindings for environments like GAE. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-413) Closing a Connection does not close Statement objects created on that connection, by way of the close() method.
[ https://issues.apache.org/jira/browse/DBCP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-413. Resolution: Invalid Feel free to reopen if / when a test case showing an actual bug can be constructed. Closing a Connection does not close Statement objects created on that connection, by way of the close() method. --- Key: DBCP-413 URL: https://issues.apache.org/jira/browse/DBCP-413 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Mark W Priority: Minor While using the MS SQL 2012 jdbc drivers with dbcp, I noticed that if you create a connection, then create a preparedStatement from that connection, and close the connection object, PreparedStatement.isClosed() will return false, but you will get a SQLException stating the statement has been closed if you attempt to call any of the set or execute methods. From the JDBC spec: Connection.close An application calls the method Connection.close() to indicate that it has finished using a connection. All Statement objects created from a given Connection object will be closed when the close method for the Connection object is called. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (MATH-982) Improvements to the User Guide
[ https://issues.apache.org/jira/browse/MATH-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz reopened MATH-982: -- Improvements to the User Guide -- Key: MATH-982 URL: https://issues.apache.org/jira/browse/MATH-982 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989195#comment-13989195 ] Phil Steitz commented on MATH-437: -- Updated user guide and TestUtils in r1592430. All that remains now is removing the deprecated classes in 4.0 Kolmogorov Smirnov Distribution --- Key: MATH-437 URL: https://issues.apache.org/jira/browse/MATH-437 Project: Commons Math Issue Type: New Feature Reporter: Mikkel Meyer Andersen Assignee: Phil Steitz Priority: Minor Fix For: 4.0 Attachments: MATH437-with-test-take-1, ks-distribution.patch Original Estimate: 0.25h Remaining Estimate: 0.25h Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a known probability density functions or if two samples are from the same distribution. To evaluate the test statistic, the Kolmogorov-Smirnov distribution is used. Quite good asymptotics exist for the one-sided test, but it's more difficult for the two-sided test. [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-412.
--
Resolution: Fixed
PDS constructor check added in r1592119
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Minor
Labels: NullPointerException, PoolableConnection
Fix For: 2.0.1
Attachments: DBCP-412.patch
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (DBCP-417) BasicManagedDataSource does not free connection after transaction is commited
[
https://issues.apache.org/jira/browse/DBCP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-417.
--
Resolution: Fixed
Patch committed in r1592132
BasicManagedDataSource does not free connection after transaction is commited
-
Key: DBCP-417
URL: https://issues.apache.org/jira/browse/DBCP-417
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Geronimo TM and JOTM, H2Database JDBC Driver
Reporter: Balazs Zsoldos
Priority: Blocker
Fix For: 2.0.1
Attachments: DBCP-417.patch, test-dbcp2-BasicManagedDataSource.zip
When a JTA Transaction is commited, the Managed connection is not available
again. The pool is becomes exhausted.
To reproduce:
{code:java}
Jotm jotm = new Jotm(true, false);
JdbcDataSource h2DataSource = new JdbcDataSource();
h2DataSource.setUrl(jdbc:h2:mem:test_mem);
BasicManagedDataSource basicManagedDataSource = new BasicManagedDataSource();
basicManagedDataSource.setTransactionManager(jotm.getTransactionManager());
basicManagedDataSource.setXaDataSourceInstance(h2DataSource);
basicManagedDataSource.setMaxTotal(2);
basicManagedDataSource.setMaxIdle(2);
UserTransaction userTransaction = jotm.getUserTransaction();
userTransaction.begin();
Connection connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
// The managed datasource will block here as there is no available connection
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
{code}
Set the priority to Blocker as BasicManagedDataSource cannot be used at all
with the bug.
Tested with Geronimo Transaction Manager and JOTM.
This worked well with version 1.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (POOL-263) GenericObjectPool close and returnObject is not synchronized
[ https://issues.apache.org/jira/browse/POOL-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979139#comment-13979139 ] Phil Steitz commented on POOL-263: -- Thanks, yangxuesong, for looking carefully at the code. The scenario you describe is made more unlikely than it may look from just the GOP code because as soon as Thread 1 starts executing idleObjects.addLast(p) it is going to acquire the lock that clear() subsequently needs, so clear() can't execute until it is finished. Look at the addLast and poll methods of LinkedBlockingDeque. It is theoretically possible however that the steps in the middle above happen between the time that idleObjects.addLast is invoked and when it acquires the lock. A test case illustrating that this can actually happen would be most appreciated. Also, any suggestions on how to ensure that it can't happen without adding material overhead to either of the methods involved. GenericObjectPool close and returnObject is not synchronized Key: POOL-263 URL: https://issues.apache.org/jira/browse/POOL-263 Project: Commons Pool Issue Type: Bug Affects Versions: 2.2 Environment: ALL Reporter: yangxuesong the javadoc on GenericObjectPool#close() says: Closes the pool. Once the pool is closed, borrowObject() will fail with IllegalStateException, but returnObject(Object) and invalidateObject(Object) will continue to work, with returned objects destroyed on return. Destroys idle instances in the pool by invoking clear(). Thread1: pool.close() Thread2: pool.returnObject() since close and returnObject is not synchronized, there is a small chance that an returned object is not destoryed after the pool is closed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13977063#comment-13977063 ] Phil Steitz commented on MATH-418: -- We are a do-ocracy here. Those who actually do the work determine what happens to the code. Ted has a cool new algorithm and implementation that he is willing to grant, but he is not willing to do the work to get it ready to commit. You have implemented a standard algorithm that is close to ready to commit. Complete the cleanup and unless others have technical issues with the code, I will commit it. add a storeless version of Percentile - Key: MATH-418 URL: https://issues.apache.org/jira/browse/MATH-418 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Luc Maisonobe Fix For: 4.0 Attachments: patch The Percentile class can handle only in-memory data. It would be interesting to use an on-line algorithm to estimate quantiles as a storeless statistic. An example of such an algorithm is the exponentially weighted stochastic approximation described in a 2000 paper by Fei Chen , Diane Lambert and José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which can be retrieved from CiteSeerX at [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (POOL-264) NullPointerException in GKOP.borrowObject()
[ https://issues.apache.org/jira/browse/POOL-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976251#comment-13976251 ] Phil Steitz commented on POOL-264: -- Thank you for reporting this. It would be great if you could provide a stack trace showing the NPE. A workaround that you can try is to leave maxActive = -1 but set WHEN_EXHAUSTED_ACTION to WHEN_EXHAUSTED_BLOCK. That may correct the sync and will achieve the same end result as negative maxActive means no limit to the number of available instances. NullPointerException in GKOP.borrowObject() --- Key: POOL-264 URL: https://issues.apache.org/jira/browse/POOL-264 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Reporter: Leonid Meyerguz While I cannot pin down a consistent repro, I occasionally observe a NullPointerException at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1126) The pool is configured as follows: maxActive = -1 maxIdle = 32 maxTotal = 32 whenExhaustedAction = WHEN_EXHAUSTED_GROW timeBetweenEvictionRunsMillis = 2 minEvictableIdleTimeMillis = 6 numTestsPerEvictionRun = -1 The NullPointerException is thrown in the WHEN_EXHAUSTED_GROW branch of the code. Specifically it appears that latch.getPool() returns null. Any suggestions for a work-around would be appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (POOL-264) NullPointerException in GKOP.borrowObject()
[ https://issues.apache.org/jira/browse/POOL-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976251#comment-13976251 ] Phil Steitz edited comment on POOL-264 at 4/22/14 12:57 AM: Thank you for reporting this. A workaround that you can try is to leave maxActive = -1 but set WHEN_EXHAUSTED_ACTION to WHEN_EXHAUSTED_BLOCK. That may correct the sync and will achieve the same end result as negative maxActive means no limit to the number of available instances per key. I think the problem here (also present in GOP) may be that the sync in the switch case block is on the pool's monitor rather than the latch. was (Author: psteitz): Thank you for reporting this. It would be great if you could provide a stack trace showing the NPE. A workaround that you can try is to leave maxActive = -1 but set WHEN_EXHAUSTED_ACTION to WHEN_EXHAUSTED_BLOCK. That may correct the sync and will achieve the same end result as negative maxActive means no limit to the number of available instances. NullPointerException in GKOP.borrowObject() --- Key: POOL-264 URL: https://issues.apache.org/jira/browse/POOL-264 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.6 Reporter: Leonid Meyerguz While I cannot pin down a consistent repro, I occasionally observe a NullPointerException at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1126) The pool is configured as follows: maxActive = -1 maxIdle = 32 maxTotal = 32 whenExhaustedAction = WHEN_EXHAUSTED_GROW timeBetweenEvictionRunsMillis = 2 minEvictableIdleTimeMillis = 6 numTestsPerEvictionRun = -1 The NullPointerException is thrown in the WHEN_EXHAUSTED_GROW branch of the code. Specifically it appears that latch.getPool() returns null. Any suggestions for a work-around would be appreciated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-412:
-
Attachment: DBCP-412.patch
Thinking about this some more, I think it would be a good idea to have the
PoolingDataSource constructor check and if necessary fix the factory-pool
linkage. Attached patch does this. Comments / better ideas welcome.
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Minor
Labels: NullPointerException, PoolableConnection
Fix For: 2.0.1
Attachments: DBCP-412.patch
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974887#comment-13974887 ] Phil Steitz commented on MATH-418: -- Thanks for the patch, Murthy! Sorry for the delay reviewing. I am not finished reviewing the implementation, but need to confirm a couple of things before plowing ahead with it: 0) You are OK removing the @author tag. We don't use those in Apache Commons. 1) The code in the patch is a clean room implementation based on the articles, not a port / translation from another source 2) You can contribute this code under the terms of the Apache Contributor's License Agreement (https://www.apache.org/licenses/icla.txt) CheckStyle and Findbugs complain about quite a few things in the source. These will need to be fixed or explained prior to commit. If you run mvn site from trunk you can see the reports. An updated patch with this stuff cleaned up would save us some time. add a storeless version of Percentile - Key: MATH-418 URL: https://issues.apache.org/jira/browse/MATH-418 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Luc Maisonobe Fix For: 4.0 Attachments: patch The Percentile class can handle only in-memory data. It would be interesting to use an on-line algorithm to estimate quantiles as a storeless statistic. An example of such an algorithm is the exponentially weighted stochastic approximation described in a 2000 paper by Fei Chen , Diane Lambert and José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which can be retrieved from CiteSeerX at [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DBCP-414) PoolablePreparedStatement can get closed while it's being used
[ https://issues.apache.org/jira/browse/DBCP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-414: - Fix Version/s: 2.0.1 PoolablePreparedStatement can get closed while it's being used -- Key: DBCP-414 URL: https://issues.apache.org/jira/browse/DBCP-414 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: DBCP 2.0 Reporter: Pasi Eronen Fix For: 2.0.1 I've found a case where a PoolablePreparedStatement that's currently in active use can get closed (resulting in PoolablePreparedStatement with address: ... is closed SQLException to the application), from a finalizer of another DelegatingPreparedStatement (that's obviously not in use, since it's being garbage collected). Details: 0. Starting point: application has a Connection (it's a PoolGuardConnectionWrapper wrapping PoolableConnection wrapping PoolingConnection wrapping com.mysql.jdbc.JDBC4Connection), statement pooling is enabled, and prepareStatement has never been called 1. Application calls conn.prepareStatement. The statement pool is empty, so this ends up in PoolingConnection.makeObject, which then calls MySQL to get a PreparedStatement (stmt1), and wraps it in PoolablePreparedStatement (stmt2). PoolableConnection.prepareStatement wraps it in new DelegatingPreparedStatement (stmt3), and PoolGuardConnectionWrapper wraps it again (stmt4). 2. Application does something with stmt4, and eventually calls stmt4.close(). The call ends up in stmt2.close (in PoolablePreparedStatement) which returns stmt2 to the statement pool. Stmt2.passivate() gets called, setting the _closed flag to true. 3. Application forgets all about stmt4 4. Later, application calls conn.prepareStatement (with same SQL) again. The result is the old MySQL PreparedStatement (stmt1) wrapped in the old PoolablePreparedStatement (stmt2) wrapped in new DelegatingPreparedStatement stmt5 wrapped in new DelegatingPreparedStatement stmt6. Stmt2.activate() gets called, setting the _closed flag to false. 5. Now, garbage collection gets run, and stmt4 gets gc'd. stmt4.finalize() calls stmt4.close() which calls stmt3.close() which calls stmt2.close(). Since stmt2 is not closed any more (_closed was just set to false above), it gets closed and returned to the pool. 6. Applications calls something in stmt6, which ends up in stmt2, and stmt2.checkOpen() throws exception java.sql.SQLException: org.apache.commons.dbcp2.PoolablePreparedStatement with address: com.mysql.jdbc.ServerPreparedStatement[12] - select 1 is closed. PoolGuardConnectionWrapper prevents the application from accidentally calling stmt4.close() later again, but this doesn't prevent the finalizer DBCP 1.4 did not have any finalizers, so it doesn't have this bug. I guess DelegatingStatement.close() should check isClosed(), and in the finally block, also do setDelegate(null) (like PoolGuardConnectionWrapper does), to make sure the delegate (which might be in active use by someone else) can never get called via this DelegatingStatement again (although most methods in DelegatingStatement start with checkOpen(), not all of them do!). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-412:
-
Priority: Minor (was: Critical)
Fix Version/s: 2.0.1
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Minor
Labels: NullPointerException, PoolableConnection
Fix For: 2.0.1
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DBCP-413) Closing a Connection does not close Statement objects created on that connection, by way of the close() method.
[ https://issues.apache.org/jira/browse/DBCP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974901#comment-13974901 ] Phil Steitz commented on DBCP-413: -- Unless a test case or code illustrating an actual bug here is provided, I am inclined to close this as invalid. Closing a Connection does not close Statement objects created on that connection, by way of the close() method. --- Key: DBCP-413 URL: https://issues.apache.org/jira/browse/DBCP-413 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Mark W Priority: Minor While using the MS SQL 2012 jdbc drivers with dbcp, I noticed that if you create a connection, then create a preparedStatement from that connection, and close the connection object, PreparedStatement.isClosed() will return false, but you will get a SQLException stating the statement has been closed if you attempt to call any of the set or execute methods. From the JDBC spec: Connection.close An application calls the method Connection.close() to indicate that it has finished using a connection. All Statement objects created from a given Connection object will be closed when the close method for the Connection object is called. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (POOL-263) GenericObjectPool close and returnObject is not synchronized
[ https://issues.apache.org/jira/browse/POOL-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974945#comment-13974945 ] Phil Steitz commented on POOL-263: -- The statement once the pool is closed means once the close method completes. At that time, subsequent returns will result in objects being destroyed. If a return happens while close is executing it is possible for an instance to return between the time close begins and the (volatile) closed property is set. In that case, the returning instance is likely to be destroyed by the clear() call at the end of close(). It does not look possible to me for an instance to sneak in after clear() has begun because closed is set before clear is invoked and clear's polling would pick up the returning instance. If someone can produce a test case indicating that it is actually possible to orphan instances this way, we can look at options for ensuring clear() on close is really effective; otherwise I am inclined to close this as invalid. GenericObjectPool close and returnObject is not synchronized Key: POOL-263 URL: https://issues.apache.org/jira/browse/POOL-263 Project: Commons Pool Issue Type: Bug Affects Versions: 2.2 Environment: ALL Reporter: yangxuesong the javadoc on GenericObjectPool#close() says: Closes the pool. Once the pool is closed, borrowObject() will fail with IllegalStateException, but returnObject(Object) and invalidateObject(Object) will continue to work, with returned objects destroyed on return. Destroys idle instances in the pool by invoking clear(). Thread1: pool.close() Thread2: pool.returnObject() since close and returnObject is not synchronized, there is a small chance that an returned object is not destoryed after the pool is closed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-417) BasicManagedDataSource does not free connection after transaction is commited
[
https://issues.apache.org/jira/browse/DBCP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974996#comment-13974996
]
Phil Steitz commented on DBCP-417:
--
Thanks for reporting this. It looks to me like this was caused by the
refactoring changes in r1547553.
BasicManagedDataSource does not free connection after transaction is commited
-
Key: DBCP-417
URL: https://issues.apache.org/jira/browse/DBCP-417
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Geronimo TM and JOTM, H2Database JDBC Driver
Reporter: Balazs Zsoldos
Priority: Blocker
Attachments: test-dbcp2-BasicManagedDataSource.zip
When a JTA Transaction is commited, the Managed connection is not available
again. The pool is becomes exhausted.
To reproduce:
{code:java}
Jotm jotm = new Jotm(true, false);
JdbcDataSource h2DataSource = new JdbcDataSource();
h2DataSource.setUrl(jdbc:h2:mem:test_mem);
BasicManagedDataSource basicManagedDataSource = new BasicManagedDataSource();
basicManagedDataSource.setTransactionManager(jotm.getTransactionManager());
basicManagedDataSource.setXaDataSourceInstance(h2DataSource);
basicManagedDataSource.setMaxTotal(2);
basicManagedDataSource.setMaxIdle(2);
UserTransaction userTransaction = jotm.getUserTransaction();
userTransaction.begin();
Connection connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
// The managed datasource will block here as there is no available connection
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
{code}
Set the priority to Blocker as BasicManagedDataSource cannot be used at all
with the bug.
Tested with Geronimo Transaction Manager and JOTM.
This worked well with version 1.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DBCP-417) BasicManagedDataSource does not free connection after transaction is commited
[
https://issues.apache.org/jira/browse/DBCP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-417:
-
Attachment: DBCP-417.patch
Test case and proposed patch. I am not sure I understand fully the intent of
the r1547553 changes, so will wait for review to commit.
BasicManagedDataSource does not free connection after transaction is commited
-
Key: DBCP-417
URL: https://issues.apache.org/jira/browse/DBCP-417
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Geronimo TM and JOTM, H2Database JDBC Driver
Reporter: Balazs Zsoldos
Priority: Blocker
Fix For: 2.0.1
Attachments: DBCP-417.patch, test-dbcp2-BasicManagedDataSource.zip
When a JTA Transaction is commited, the Managed connection is not available
again. The pool is becomes exhausted.
To reproduce:
{code:java}
Jotm jotm = new Jotm(true, false);
JdbcDataSource h2DataSource = new JdbcDataSource();
h2DataSource.setUrl(jdbc:h2:mem:test_mem);
BasicManagedDataSource basicManagedDataSource = new BasicManagedDataSource();
basicManagedDataSource.setTransactionManager(jotm.getTransactionManager());
basicManagedDataSource.setXaDataSourceInstance(h2DataSource);
basicManagedDataSource.setMaxTotal(2);
basicManagedDataSource.setMaxIdle(2);
UserTransaction userTransaction = jotm.getUserTransaction();
userTransaction.begin();
Connection connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
// The managed datasource will block here as there is no available connection
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
{code}
Set the priority to Blocker as BasicManagedDataSource cannot be used at all
with the bug.
Tested with Geronimo Transaction Manager and JOTM.
This worked well with version 1.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (DBCP-417) BasicManagedDataSource does not free connection after transaction is commited
[
https://issues.apache.org/jira/browse/DBCP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-417:
-
Fix Version/s: 2.0.1
BasicManagedDataSource does not free connection after transaction is commited
-
Key: DBCP-417
URL: https://issues.apache.org/jira/browse/DBCP-417
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Geronimo TM and JOTM, H2Database JDBC Driver
Reporter: Balazs Zsoldos
Priority: Blocker
Fix For: 2.0.1
Attachments: DBCP-417.patch, test-dbcp2-BasicManagedDataSource.zip
When a JTA Transaction is commited, the Managed connection is not available
again. The pool is becomes exhausted.
To reproduce:
{code:java}
Jotm jotm = new Jotm(true, false);
JdbcDataSource h2DataSource = new JdbcDataSource();
h2DataSource.setUrl(jdbc:h2:mem:test_mem);
BasicManagedDataSource basicManagedDataSource = new BasicManagedDataSource();
basicManagedDataSource.setTransactionManager(jotm.getTransactionManager());
basicManagedDataSource.setXaDataSourceInstance(h2DataSource);
basicManagedDataSource.setMaxTotal(2);
basicManagedDataSource.setMaxIdle(2);
UserTransaction userTransaction = jotm.getUserTransaction();
userTransaction.begin();
Connection connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
// The managed datasource will block here as there is no available connection
userTransaction.begin();
connection = basicManagedDataSource.getConnection();
connection.close();
userTransaction.commit();
{code}
Set the priority to Blocker as BasicManagedDataSource cannot be used at all
with the bug.
Tested with Geronimo Transaction Manager and JOTM.
This worked well with version 1.4.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DBCP-414) PoolablePreparedStatement can get closed while it's being used
[ https://issues.apache.org/jira/browse/DBCP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13974631#comment-13974631 ] Phil Steitz commented on DBCP-414: -- Test committed in r1588592 verifying that DelegatingStatement close does not re-close wrapped PPS. Per comments in the description, DBCP itself did not expose this bug prior to 2.0. The changes for DBCP-180 exposed it. Thanks, Pasi, for the report and analysis. PoolablePreparedStatement can get closed while it's being used -- Key: DBCP-414 URL: https://issues.apache.org/jira/browse/DBCP-414 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: DBCP 2.0 Reporter: Pasi Eronen I've found a case where a PoolablePreparedStatement that's currently in active use can get closed (resulting in PoolablePreparedStatement with address: ... is closed SQLException to the application), from a finalizer of another DelegatingPreparedStatement (that's obviously not in use, since it's being garbage collected). Details: 0. Starting point: application has a Connection (it's a PoolGuardConnectionWrapper wrapping PoolableConnection wrapping PoolingConnection wrapping com.mysql.jdbc.JDBC4Connection), statement pooling is enabled, and prepareStatement has never been called 1. Application calls conn.prepareStatement. The statement pool is empty, so this ends up in PoolingConnection.makeObject, which then calls MySQL to get a PreparedStatement (stmt1), and wraps it in PoolablePreparedStatement (stmt2). PoolableConnection.prepareStatement wraps it in new DelegatingPreparedStatement (stmt3), and PoolGuardConnectionWrapper wraps it again (stmt4). 2. Application does something with stmt4, and eventually calls stmt4.close(). The call ends up in stmt2.close (in PoolablePreparedStatement) which returns stmt2 to the statement pool. Stmt2.passivate() gets called, setting the _closed flag to true. 3. Application forgets all about stmt4 4. Later, application calls conn.prepareStatement (with same SQL) again. The result is the old MySQL PreparedStatement (stmt1) wrapped in the old PoolablePreparedStatement (stmt2) wrapped in new DelegatingPreparedStatement stmt5 wrapped in new DelegatingPreparedStatement stmt6. Stmt2.activate() gets called, setting the _closed flag to false. 5. Now, garbage collection gets run, and stmt4 gets gc'd. stmt4.finalize() calls stmt4.close() which calls stmt3.close() which calls stmt2.close(). Since stmt2 is not closed any more (_closed was just set to false above), it gets closed and returned to the pool. 6. Applications calls something in stmt6, which ends up in stmt2, and stmt2.checkOpen() throws exception java.sql.SQLException: org.apache.commons.dbcp2.PoolablePreparedStatement with address: com.mysql.jdbc.ServerPreparedStatement[12] - select 1 is closed. PoolGuardConnectionWrapper prevents the application from accidentally calling stmt4.close() later again, but this doesn't prevent the finalizer DBCP 1.4 did not have any finalizers, so it doesn't have this bug. I guess DelegatingStatement.close() should check isClosed(), and in the finally block, also do setDelegate(null) (like PoolGuardConnectionWrapper does), to make sure the delegate (which might be in active use by someone else) can never get called via this DelegatingStatement again (although most methods in DelegatingStatement start with checkOpen(), not all of them do!). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-414) PoolablePreparedStatement can get closed while it's being used
[ https://issues.apache.org/jira/browse/DBCP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13972024#comment-13972024 ] Phil Steitz commented on DBCP-414: -- I think the analysis in the bug description is correct. In r1588087, I changed DelegatingStatement close to null the delegate reference and no-op on close. All tests pass now. Leaving open for now, pending review. PoolablePreparedStatement can get closed while it's being used -- Key: DBCP-414 URL: https://issues.apache.org/jira/browse/DBCP-414 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: DBCP 2.0 Reporter: Pasi Eronen I've found a case where a PoolablePreparedStatement that's currently in active use can get closed (resulting in PoolablePreparedStatement with address: ... is closed SQLException to the application), from a finalizer of another DelegatingPreparedStatement (that's obviously not in use, since it's being garbage collected). Details: 0. Starting point: application has a Connection (it's a PoolGuardConnectionWrapper wrapping PoolableConnection wrapping PoolingConnection wrapping com.mysql.jdbc.JDBC4Connection), statement pooling is enabled, and prepareStatement has never been called 1. Application calls conn.prepareStatement. The statement pool is empty, so this ends up in PoolingConnection.makeObject, which then calls MySQL to get a PreparedStatement (stmt1), and wraps it in PoolablePreparedStatement (stmt2). PoolableConnection.prepareStatement wraps it in new DelegatingPreparedStatement (stmt3), and PoolGuardConnectionWrapper wraps it again (stmt4). 2. Application does something with stmt4, and eventually calls stmt4.close(). The call ends up in stmt2.close (in PoolablePreparedStatement) which returns stmt2 to the statement pool. Stmt2.passivate() gets called, setting the _closed flag to true. 3. Application forgets all about stmt4 4. Later, application calls conn.prepareStatement (with same SQL) again. The result is the old MySQL PreparedStatement (stmt1) wrapped in the old PoolablePreparedStatement (stmt2) wrapped in new DelegatingPreparedStatement stmt5 wrapped in new DelegatingPreparedStatement stmt6. Stmt2.activate() gets called, setting the _closed flag to false. 5. Now, garbage collection gets run, and stmt4 gets gc'd. stmt4.finalize() calls stmt4.close() which calls stmt3.close() which calls stmt2.close(). Since stmt2 is not closed any more (_closed was just set to false above), it gets closed and returned to the pool. 6. Applications calls something in stmt6, which ends up in stmt2, and stmt2.checkOpen() throws exception java.sql.SQLException: org.apache.commons.dbcp2.PoolablePreparedStatement with address: com.mysql.jdbc.ServerPreparedStatement[12] - select 1 is closed. PoolGuardConnectionWrapper prevents the application from accidentally calling stmt4.close() later again, but this doesn't prevent the finalizer DBCP 1.4 did not have any finalizers, so it doesn't have this bug. I guess DelegatingStatement.close() should check isClosed(), and in the finally block, also do setDelegate(null) (like PoolGuardConnectionWrapper does), to make sure the delegate (which might be in active use by someone else) can never get called via this DelegatingStatement again (although most methods in DelegatingStatement start with checkOpen(), not all of them do!). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969700#comment-13969700 ] Phil Steitz commented on DBCP-415: -- The problem, if I understand the intent of DBCP-180 and the current code correctly, is that when statement pooling is not enabled, you do in fact need to clean up DelegatingStatements. The one case where you do *not* want to close-on-finalize is when the DelegatingStatement is wrapped by a PPS. So it seems to me the safest thing to do is to find a way to guard on that condition. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969745#comment-13969745 ] Phil Steitz commented on DBCP-415: -- @Bernd - I agree with you, which is why I participated in the multi-year punting of DBCP-180. Have a look at that issue, which explains why the finalizer is there (I think). Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-414) PoolablePreparedStatement can get closed while it's being used
[ https://issues.apache.org/jira/browse/DBCP-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970043#comment-13970043 ] Phil Steitz commented on DBCP-414: -- See comments on the duplicate issue, DBCP-415 PoolablePreparedStatement can get closed while it's being used -- Key: DBCP-414 URL: https://issues.apache.org/jira/browse/DBCP-414 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Environment: DBCP 2.0 Reporter: Pasi Eronen I've found a case where a PoolablePreparedStatement that's currently in active use can get closed (resulting in PoolablePreparedStatement with address: ... is closed SQLException to the application), from a finalizer of another DelegatingPreparedStatement (that's obviously not in use, since it's being garbage collected). Details: 0. Starting point: application has a Connection (it's a PoolGuardConnectionWrapper wrapping PoolableConnection wrapping PoolingConnection wrapping com.mysql.jdbc.JDBC4Connection), statement pooling is enabled, and prepareStatement has never been called 1. Application calls conn.prepareStatement. The statement pool is empty, so this ends up in PoolingConnection.makeObject, which then calls MySQL to get a PreparedStatement (stmt1), and wraps it in PoolablePreparedStatement (stmt2). PoolableConnection.prepareStatement wraps it in new DelegatingPreparedStatement (stmt3), and PoolGuardConnectionWrapper wraps it again (stmt4). 2. Application does something with stmt4, and eventually calls stmt4.close(). The call ends up in stmt2.close (in PoolablePreparedStatement) which returns stmt2 to the statement pool. Stmt2.passivate() gets called, setting the _closed flag to true. 3. Application forgets all about stmt4 4. Later, application calls conn.prepareStatement (with same SQL) again. The result is the old MySQL PreparedStatement (stmt1) wrapped in the old PoolablePreparedStatement (stmt2) wrapped in new DelegatingPreparedStatement stmt5 wrapped in new DelegatingPreparedStatement stmt6. Stmt2.activate() gets called, setting the _closed flag to false. 5. Now, garbage collection gets run, and stmt4 gets gc'd. stmt4.finalize() calls stmt4.close() which calls stmt3.close() which calls stmt2.close(). Since stmt2 is not closed any more (_closed was just set to false above), it gets closed and returned to the pool. 6. Applications calls something in stmt6, which ends up in stmt2, and stmt2.checkOpen() throws exception java.sql.SQLException: org.apache.commons.dbcp2.PoolablePreparedStatement with address: com.mysql.jdbc.ServerPreparedStatement[12] - select 1 is closed. PoolGuardConnectionWrapper prevents the application from accidentally calling stmt4.close() later again, but this doesn't prevent the finalizer DBCP 1.4 did not have any finalizers, so it doesn't have this bug. I guess DelegatingStatement.close() should check isClosed(), and in the finally block, also do setDelegate(null) (like PoolGuardConnectionWrapper does), to make sure the delegate (which might be in active use by someone else) can never get called via this DelegatingStatement again (although most methods in DelegatingStatement start with checkOpen(), not all of them do!). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-415. Resolution: Duplicate Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970040#comment-13970040 ] Phil Steitz commented on DBCP-415: -- Thanks, Pasi, you are correct. I somehow missed that report before opening this one. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1118) Complex: semantics of equals != Double equals, mismatch with hashCode
[ https://issues.apache.org/jira/browse/MATH-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968973#comment-13968973 ] Phil Steitz commented on MATH-1118: --- Given the decision in MATH-221, I am inclined to agree that the better approach is to just fix the hashcode impl. Complex: semantics of equals != Double equals, mismatch with hashCode - Key: MATH-1118 URL: https://issues.apache.org/jira/browse/MATH-1118 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Attachments: MATH-1118.patch, Report5.java, Report5a.java Two complex numbers with real/imaginary parts 0.0d but different signs compare as equal numbers. This is according to their mathematical value; the comparison is done via return (real == c.real) (imaginary == c.imaginary); Unfortunately, two Double values do NOT compare as equal in that case, so real.equals(c.real) would return false if the signs differ. This becomes a problem because for the hashCode, MathUtils.hash is used on the real and imaginary parts, which in turn uses Double.hash. This violates the contract on equals/hashCode, so Complex numbers cannot be used in a hashtable or similar data structure: Complex c1 = new Complex(0.0, 0.0); Complex c2 = new Complex(0.0, -0.0); // Checks the contract: equals-hashcode on c1 and c2 assertTrue(Contract failed: equals-hashcode on c1 and c2, c1.equals(c2) ? c1.hashCode() == c2.hashCode() : true); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969231#comment-13969231 ] Phil Steitz commented on DBCP-415: -- Returning to the actual issue here, I am not sure now I really get the need for the finalizer as described in the javadoc for DelegatingStatement#finalize. When statement pooling is enabled the PoolableXxxStatements are strongly held by the statement pool in the allObjects maps under their keys, so I don't see how they end up garbage collected. On the other hand, I can see why the close needs to be there on finalization if we want the auto-cleanup behavior asked for in POOL-180. Unfortunately, IIUC what is going on here, the change that I suggested above will not trigger the close-on-GC behavior in general. If we want both, we probably need to explicitly guard against the case where a DelegatingStatement is wrapped by a PoolableXxxStatement. Could be I am missing something about the issue and fix for POOL-180. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (DBCP-415) Pooled PreparedStatements may be closed when accessed
Phil Steitz created DBCP-415: Summary: Pooled PreparedStatements may be closed when accessed Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967745#comment-13967745 ] Phil Steitz commented on DBCP-415: -- Test case (commented out) added to TestPStmtPoolingBasicDataSource to illustrate this bug. I think this is likely a regression due to the fix for DBCP-180. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967745#comment-13967745 ] Phil Steitz edited comment on DBCP-415 at 4/13/14 6:19 AM: --- Test case (commented out) added to TestPStmtPoolingBasicDataSource in r1586926 to illustrate this bug. I think this is likely a regression due to the fix for DBCP-180. was (Author: psteitz): Test case (commented out) added to TestPStmtPoolingBasicDataSource to illustrate this bug. I think this is likely a regression due to the fix for DBCP-180. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967930#comment-13967930 ] Phil Steitz commented on DBCP-415: -- The test succeeds if I move the finalizer for DelegatingStatment to PoolablePreparedStatement (and to PoolableCalledStatement too). I think that what is going on here is that PoolablePreparedStatements themselves wrap DelegatingStatements (created by their owning PoolingConnection's delegate) and we don't want these wrapped statements to be closed by finalizers. Limiting close-by-finalizer to the PoolableXxxStatements themselves gets them returned to the pool and does not have this effect. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (DBCP-416) TestConnectionPool.testThreaded() sometimes fails
[
https://issues.apache.org/jira/browse/DBCP-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-416.
Resolution: Duplicate
The changes committed in r1586926 were to make this happen consistently.
TestConnectionPool.testThreaded() sometimes fails
-
Key: DBCP-416
URL: https://issues.apache.org/jira/browse/DBCP-416
Project: Commons Dbcp
Issue Type: Bug
Reporter: Sebb
TestConnectionPool.testThreaded() sometimes fails for me:
{code}
java.sql.SQLException: org.apache.commons.dbcp2.PoolablePreparedStatement
with address: select 'literal', SYSDATE from dual is closed.
at
org.apache.commons.dbcp2.DelegatingStatement.checkOpen(DelegatingStatement.java:120)
at
org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:77)
at
org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
at
org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
at
org.apache.commons.dbcp2.TestConnectionPool$TestThread.run(TestConnectionPool.java:601)
at java.lang.Thread.run(Thread.java:744)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DBCP-415) Pooled PreparedStatements may be closed when accessed
[ https://issues.apache.org/jira/browse/DBCP-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968045#comment-13968045 ] Phil Steitz commented on DBCP-415: -- @Sebb - I don't think that is actually a problem. Only one thread at a time should have access to a given PoolingConnection at a time (else we have a [pool] problem, which I first thought this might be, but now think it is not). As long as clients adhere to the pool contract (which I am pretty sure DBCP does and I know the test code does from DBCP standpoint - no retained references / use after connection close), there will be no concurrent access to a single PoolingConnection. In addition to that protection, the PoolalePreparedStatements are accessed only through their PooledObject wrappers in the GKOP owned by the PoolingConnection that they belong to. I could be wrong, but I am pretty sure that the problem here is the back door access to the DelegatingStatement via the finalizer. I am -0 to the volatile changes, OK if they can be shown to have zero performance impact. Pooled PreparedStatements may be closed when accessed - Key: DBCP-415 URL: https://issues.apache.org/jira/browse/DBCP-415 Project: Commons Dbcp Issue Type: Bug Affects Versions: 2.0 Reporter: Phil Steitz Under high concurrency, connections using pooled PreparedStatements may encounter SQLExceptions with messages of the form org.apache.commons.dbcp2.PoolablePreparedStatement with address: 'quoted SQL' is closed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967743#comment-13967743 ] Phil Steitz commented on MATH-418: -- Can you please submit the changes as a patch against trunk in svn? add a storeless version of Percentile - Key: MATH-418 URL: https://issues.apache.org/jira/browse/MATH-418 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Luc Maisonobe Fix For: 4.0 The Percentile class can handle only in-memory data. It would be interesting to use an on-line algorithm to estimate quantiles as a storeless statistic. An example of such an algorithm is the exponentially weighted stochastic approximation described in a 2000 paper by Fei Chen , Diane Lambert and José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which can be retrieved from CiteSeerX at [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-413) Closing a Connection does not close Statement objects created on that connection, by way of the close() method.
[ https://issues.apache.org/jira/browse/DBCP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13965534#comment-13965534 ] Phil Steitz commented on DBCP-413: -- DBCP should both set the isClosed property on its wrapper for the PreparedStatement and close the actual JDBC statement when a connection borrowed from the pool is closed. The driver should treat repeated close on a statement as no-op. What does not make sense in this case is isClosed returning false. That could point to a DBCP bug (though not what the title for this issue suggests). If statement pooling is enabled and there are concurrent clients involved, this scenario is possible with the right timing and does not indicate a bug in DBCP - just reconfirms that clients should *not* use anything associated with a connection once it has been returned to the pool. Closing a Connection does not close Statement objects created on that connection, by way of the close() method. --- Key: DBCP-413 URL: https://issues.apache.org/jira/browse/DBCP-413 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Mark W Priority: Minor While using the MS SQL 2012 jdbc drivers with dbcp, I noticed that if you create a connection, then create a preparedStatement from that connection, and close the connection object, PreparedStatement.isClosed() will return false, but you will get a SQLException stating the statement has been closed if you attempt to call any of the set or execute methods. From the JDBC spec: Connection.close An application calls the method Connection.close() to indicate that it has finished using a connection. All Statement objects created from a given Connection object will be closed when the close method for the Connection object is called. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-413) Closing a Connection does not close Statement objects created on that connection, by way of the close() method.
[ https://issues.apache.org/jira/browse/DBCP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13964885#comment-13964885 ] Phil Steitz commented on DBCP-413: -- Do you have statement pooling configured? In general, once you close a connection, your client code should discard references to and not attempt further operations on the connection or any statements or resultsets created using it. DBCP does try to comply with the spec above so in fact the statements should be getting closed on connection close. Can you provide more info on exactly what your client code is doing? Closing a Connection does not close Statement objects created on that connection, by way of the close() method. --- Key: DBCP-413 URL: https://issues.apache.org/jira/browse/DBCP-413 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Mark W Priority: Minor While using the MS SQL 2012 jdbc drivers with dbcp, I noticed that if you create a connection, then create a preparedStatement from that connection, and close the connection object, PreparedStatement.isClosed() will return false, but you will get a SQLException stating the statement has been closed if you attempt to call any of the set or execute methods. From the JDBC spec: Connection.close An application calls the method Connection.close() to indicate that it has finished using a connection. All Statement objects created from a given Connection object will be closed when the close method for the Connection object is called. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959971#comment-13959971
]
Phil Steitz commented on DBCP-412:
--
The difference in behavior is likely due to the changes in DBCP-358. The
hashcodes you are examining are those of the DelegatingConnection instances
returned by PoolingDataSource. As of 2.0, DelegatingConnection instances
wrapping the same underlying physical connection are not equal. If you have a
way to see the physical connections in the database, you should be able to
verify that there is just one being used by the code (else there is a bug here).
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Critical
Labels: NullPointerException, PoolableConnection
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13960959#comment-13960959
]
Phil Steitz commented on DBCP-412:
--
Sample code in PoolingDataSourceExample fixed in r1584958.
Still to do:
* Update other examples (incl header comments)
* Add unit tests to verify examples work - for this example, either
TesterDriver has to modified to handle uid/pwd in URL or example has to set
props
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Critical
Labels: NullPointerException, PoolableConnection
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (POOL-262) Make GOP/GKOP fairness configurable
Phil Steitz created POOL-262: Summary: Make GOP/GKOP fairness configurable Key: POOL-262 URL: https://issues.apache.org/jira/browse/POOL-262 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.2, 2.1, 2.0 Reporter: Phil Steitz Priority: Minor GenericObjectPool, GenericKeyedObjectPool should be configurable to support fairness. When configured to be fair, pools should serve client requests in arrival order. Since client threads perform creates, this does not mean client threads will necessarily always complete in arrival order. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959040#comment-13959040
]
Phil Steitz commented on DBCP-412:
--
The problem is in the example code. In version 2, the
PoolableConnectionFactory constructor no longer takes the parent pool as a
parameter. To correctly set up the pool manually, we need to set the pool
property of the PoolableConnectionFactory using its setPool method. So above
we need to add
{code} poolableConnectionFactory.setPool(connectionPool) {code}
We should fix this in the example and add unit tests confirming that the
examples work. Patches welcome.
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Critical
Labels: NullPointerException, PoolableConnection
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959087#comment-13959087
]
Phil Steitz commented on DBCP-412:
--
It might also a good idea to have the PoolingDataSource constructor check that
its factory refers back to itself.
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Critical
Labels: NullPointerException, PoolableConnection
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (DBCP-412) dbcp2.PoolableConnection.close raises NullPointerException
[
https://issues.apache.org/jira/browse/DBCP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959087#comment-13959087
]
Phil Steitz edited comment on DBCP-412 at 4/3/14 7:00 PM:
--
It might also a good idea to have the PoolingDataSource constructor check that
its pool's factory refers back to itself.
was (Author: psteitz):
It might also a good idea to have the PoolingDataSource constructor check that
its factory refers back to itself.
dbcp2.PoolableConnection.close raises NullPointerException
--
Key: DBCP-412
URL: https://issues.apache.org/jira/browse/DBCP-412
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 2.0
Environment: Mac OSX, Java 7, SQLAzure
Reporter: Davide Caroselli
Priority: Critical
Labels: NullPointerException, PoolableConnection
I found a critical error while closing a PoolableConnection.
Here's the code to reproduce the bug (largely copied from the example shown
in the Apache DBCP site):
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
public static void main(String[] args) throws Throwable {
Class.forName(com.microsoft.sqlserver.jdbc.SQLServerDriver);
DataSource dataSource = setupDataSource(jdbcUrl);
Connection connection = null;
PreparedStatement statement = null;
ResultSet result = null;
try {
connection = dataSource.getConnection();
statement = connection.prepareStatement(SELECT 1);
result = statement.executeQuery();
} finally {
result.close();
statement.close();
connection.close();
}
}
public static DataSource setupDataSource(String connectURI) {
ConnectionFactory connectionFactory = new
DriverManagerConnectionFactory(connectURI, null);
PoolableConnectionFactory poolableConnectionFactory = new
PoolableConnectionFactory(connectionFactory, null);
ObjectPoolPoolableConnection connectionPool = new
GenericObjectPool(poolableConnectionFactory);
PoolingDataSourcePoolableConnection dataSource = new
PoolingDataSource(connectionPool);
return dataSource;
}
{code}
When the code tries to close the connection (in the final block), an
exception is raised:
{code:title=PoolingDataSourceExample2.java|borderStyle=solid}
Exception in thread main java.lang.NullPointerException
at
org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:151)
at
org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:235)
at
org.apache.commons.dbcp2.DelegatingConnection.close(DelegatingConnection.java:218)
at
org.apache.commons.dbcp2.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:212)
at
dbcp.PoolingDataSourceExample2.closeQuietly(PoolingDataSourceExample2.java:64)
at
dbcp.PoolingDataSourceExample2.main(PoolingDataSourceExample2.java:43){code}
As I can see, the problem is the _pool variable inside PoolableConnection
but I could not find any solution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (MATH-1112) Implementation of Percentile function that does not need to store values
[ https://issues.apache.org/jira/browse/MATH-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed MATH-1112. - Resolution: Duplicate Per comments on the mailing list, this issue duplicates MATH-418. Please add comments / patches to that ticket. Implementation of Percentile function that does not need to store values Key: MATH-1112 URL: https://issues.apache.org/jira/browse/MATH-1112 Project: Commons Math Issue Type: New Feature Affects Versions: 3.2, 3.3 Environment: Java supported platform Reporter: Venkatesha Murthy TS Labels: Percentile Original Estimate: 336h Remaining Estimate: 336h A new implementation of Percentile calculation based on P Square algorithm( http://www.cse.wustl.edu/~jain/papers/psqr.htm) is being proposed here. This new implementation has key advantage that it doesn't need to store inputs and needs a constant space to compute the percentile as the input is consumed. This advantage is much required when used in computing the percentiles at big-data scale or for in-stream analytics. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (POOL-259) Client wait time is not updated when max wait is configured to be unlimited
Phil Steitz created POOL-259: Summary: Client wait time is not updated when max wait is configured to be unlimited Key: POOL-259 URL: https://issues.apache.org/jira/browse/POOL-259 Project: Commons Pool Issue Type: Bug Reporter: Phil Steitz The local variable waitTime used by borrowObject in both GOP and GKOP is not updated unless borrowMaxWaitMillis is non-negative and blockeWhenExhausted is true. This effectively zeros the JMX client wait time properties for these configurations. Even when there is a maxWait configured and the pool is set to block when exhausted, what ends up being reported is only the wait time on the instance queue. I am inclined to fix this by setting waitTime at the beginning and updating it at the end (including activate and validate times). We should also add test cases for this and the other stats exposed via JMX. Patches welcome, as it may take me a little while to get to this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (POOL-259) Client wait time is not updated when max wait is configured to be unlimited
[ https://issues.apache.org/jira/browse/POOL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-259: - Affects Version/s: 2.2 Client wait time is not updated when max wait is configured to be unlimited --- Key: POOL-259 URL: https://issues.apache.org/jira/browse/POOL-259 Project: Commons Pool Issue Type: Bug Affects Versions: 2.2 Reporter: Phil Steitz The local variable waitTime used by borrowObject in both GOP and GKOP is not updated unless borrowMaxWaitMillis is non-negative and blockeWhenExhausted is true. This effectively zeros the JMX client wait time properties for these configurations. Even when there is a maxWait configured and the pool is set to block when exhausted, what ends up being reported is only the wait time on the instance queue. I am inclined to fix this by setting waitTime at the beginning and updating it at the end (including activate and validate times). We should also add test cases for this and the other stats exposed via JMX. Patches welcome, as it may take me a little while to get to this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (POOL-259) Client wait time is not updated when max wait is configured to be unlimited
[ https://issues.apache.org/jira/browse/POOL-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-259: - Description: The local variable waitTime used by borrowObject in both GOP and GKOP is not updated unless borrowMaxWaitMillis is non-negative and blockWhenExhausted is true. This effectively zeros the JMX client wait time properties for these configurations. Even when there is a maxWait configured and the pool is set to block when exhausted, what ends up being reported is only the wait time on the instance queue. Note that this bug is JMX reporting only. I am inclined to fix this by setting waitTime at the beginning and updating it at the end (including activate and validate times). We should also add test cases for this and the other stats exposed via JMX. Patches welcome, as it may take me a little while to get to this. was:The local variable waitTime used by borrowObject in both GOP and GKOP is not updated unless borrowMaxWaitMillis is non-negative and blockeWhenExhausted is true. This effectively zeros the JMX client wait time properties for these configurations. Even when there is a maxWait configured and the pool is set to block when exhausted, what ends up being reported is only the wait time on the instance queue. I am inclined to fix this by setting waitTime at the beginning and updating it at the end (including activate and validate times). We should also add test cases for this and the other stats exposed via JMX. Patches welcome, as it may take me a little while to get to this. Client wait time is not updated when max wait is configured to be unlimited --- Key: POOL-259 URL: https://issues.apache.org/jira/browse/POOL-259 Project: Commons Pool Issue Type: Bug Affects Versions: 2.2 Reporter: Phil Steitz The local variable waitTime used by borrowObject in both GOP and GKOP is not updated unless borrowMaxWaitMillis is non-negative and blockWhenExhausted is true. This effectively zeros the JMX client wait time properties for these configurations. Even when there is a maxWait configured and the pool is set to block when exhausted, what ends up being reported is only the wait time on the instance queue. Note that this bug is JMX reporting only. I am inclined to fix this by setting waitTime at the beginning and updating it at the end (including activate and validate times). We should also add test cases for this and the other stats exposed via JMX. Patches welcome, as it may take me a little while to get to this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1110) OLSMultipleLinearRegression needs a way to specify non-zero singularity threshold when instantiating QRDecomposition
[ https://issues.apache.org/jira/browse/MATH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13936276#comment-13936276 ] Phil Steitz commented on MATH-1110: --- Agreed this should be fixed. The default should not be 0 and it should be configurable. Patches welcome. OLSMultipleLinearRegression needs a way to specify non-zero singularity threshold when instantiating QRDecomposition Key: MATH-1110 URL: https://issues.apache.org/jira/browse/MATH-1110 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Windows 7, jdk1.6.0_45 Reporter: Edward Segall OLSMultipleLinearRegression uses QRDecomposition to perform a least-squares solution. QRDecomposition has the capability to use a non-zero threshold for detecting when the design matrix is singular (see https://issues.apache.org/jira/browse/MATH-665, https://issues.apache.org/jira/browse/MATH-1024, https://issues.apache.org/jira/browse/MATH-1100, https://issues.apache.org/jira/browse/MATH-1101) but OLSMultipleLinearRegression does not use this capability and therefore always uses the default singularity test threshold of 0. This can lead to bad solutions (see in particular https://issues.apache.org/jira/browse/MATH-1101?focusedCommentId=13909750page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13909750) when a SingularMatrixException should instead be thrown. When I encountered this situation, I noticed it because the solution values were extremely large (in the range 1e09 - 1e12). Normal values in the domain I am working with are on the order of 1e-3. To find out why the values are so large, I traced through the source and found that an rDiag value was on the order of 1e-15, and that this passed the threshold test. I then noticed that two columns of the design matrix are linearly dependent (one column is all 1's because I want an intercept value in the solution, and another is also all 1's because that's how the data worked out). Thus the matrix is definitely singular. If I could specify a non-zero threshold, this situation would result in a SingularMatrixException, but without that, the bad solution values would be blindly propagated. That is a problem because this solution is intended for controlling a physical system, and damage could result from a bad solution. Unfortunately, I see no way to change the threshold value from outside -- I would have to in effect re-implement OLSMultipleLinearRegression to do this as a user of the package. -- This message was sent by Atlassian JIRA (v6.2#6252)
