[jira] [Updated] (DBCP-260) borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set
[ https://issues.apache.org/jira/browse/DBCP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-260: - Affects Version/s: 1.3 1.4 > borrowObject from the AbandonedObjectPool hangs on a wait() method when the > WHEN_EXHAUSTED_BLOCK is set > --- > > Key: DBCP-260 > URL: https://issues.apache.org/jira/browse/DBCP-260 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 1.2, 1.2.1, 1.2.2, 1.3, 1.4 > Environment: Windows XP, eclipse. JDK 1.6 >Reporter: Meir Shahar >Priority: Minor > Fix For: 2.0 > > > This bug is related to bugs #1, #38 & #102. Thought the bugs are closed, I > think there is a (edge condition) scenario that is not handled properly: > Config: > 10 active connections limit > RemoveAbandoned set to 'on' > RemoveAbandonedTimeout set to x (say 60 secs) > Suppose 10 connections were borrowed and the 11 th request was issued, all > within a time frame shorted then the timeout. > The first 10 requests are in methods that do not properly release the > connection. > This means that the 11 th thread is waiting indefinitely until a notify is > sent. > The 'non releasing' threads the first 10 connections hence no notification is > sent > The 'garbage collection' is performed by the calling AbandonedObjectPool > before calling the GenericObjectPool.borrowObject(...). This garbage > collection will not be called again and the wait() will stay locked though > some connections might be come available through timeout expiration. > The quick n dirty workaround is to setMaxWait(...) but still I think a better > solution will be along the lines of: > 1. Waiting for removeAbandonedTimeout secs > 2. Retry regular allocation -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 updated DBCP-300: - Affects Version/s: 1.3 1.4 > 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DBCP-335) NPE with MySQL PreparedStatement
[
https://issues.apache.org/jira/browse/DBCP-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-335.
Resolution: Cannot Reproduce
Please reopen if you can provide a test case showing that this is in fact a
pool or dbcp bug.
> NPE with MySQL PreparedStatement
>
>
> Key: DBCP-335
> URL: https://issues.apache.org/jira/browse/DBCP-335
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: CloudFoundry, Linux, Sun Java 1.6.0_04, Grails 1.2.2,
> MySQL Connector 5.1.12
>Reporter: Marcus Better
>
> My Grails application using MySQL and DBCP often throws an exception as
> below. I can trigger it by making a simultaneous requests (three at a time)
> on differend threads in a ThreadPoolExecutor. The requests would all use the
> same query. This triggers the exception with a few percent probability.
> I have tried with DBCP 1.2.2 and 1.4.
> There is a similar-looking [MySQL bug|http://bugs.mysql.com/bug.php?id=41628]
> but they blame the pool...
> {code}
> Exception in thread "pool-1-thread-12" java.lang.NullPointerException
> at
> com.mysql.jdbc.PreparedStatement.fillSendPacket(PreparedStatement.java:2475)
> at
> com.mysql.jdbc.PreparedStatement.fillSendPacket(PreparedStatement.java:2451)
> at
> com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2205)
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> at
> org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1808)
> at org.hibernate.loader.Loader.doQuery(Loader.java:697)
> at
> org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
> at org.hibernate.loader.Loader.loadEntity(Loader.java:1881)
> at
> org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:71)
> at
> org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:65)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3072)
> at
> org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:434)
> at
> org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:415)
> at
> org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:165)
> at
> org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:121)
> at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:905)
> at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:863)
> at
> org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:95)
> at
> org.codehaus.groovy.grails.orm.hibernate.proxy.HibernateProxyHandler.unwrapProxy(HibernateProxyHandler.java:80)
> at
> org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsHibernateUtil.unwrapProxy(GrailsHibernateUtil.java:322)
> at
> org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsHibernateUtil$unwrapProxy.call(Unknown
> Source)
> at
> org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport$__clinit__closure88.doCall(HibernatePluginSupport.groovy:401)
> at sun.reflect.GeneratedMethodAccessor381.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
> at
> org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
> at
> org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport$__clinit__closure88.call(HibernatePluginSupport.groovy)
> at sun.reflect.GeneratedMethodAccessor380.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1049)
> at
> groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.j
[jira] [Updated] (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 updated DBCP-355:
-
Fix Version/s: 1.4.1
1.3.1
> 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.3.1, 1.4.1
>
>
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 updated DBCP-353: - Fix Version/s: 1.4.1 1.3.1 > 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 updated DBCP-356: - Fix Version/s: 1.4.1 1.3.1 > 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 > > > 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.(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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 updated DBCP-357: - Fix Version/s: 2.0 > 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13027351#comment-13027351 ] Phil Steitz commented on DBCP-357: -- Looks like a good enhancement for 2.0. We should probably make it configurable, though, whether to rely on the driver implementation or actually fire the validation query. > 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-218) Add function similar to getOptionValue() that returns last value
[ https://issues.apache.org/jira/browse/CLI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027338#comment-13027338 ] Sven commented on CLI-218: -- Also, the documentation of getOptionValue() doesn't even mention whether the last or first value is returned. This should be fixed as well. > Add function similar to getOptionValue() that returns last value > > > Key: CLI-218 > URL: https://issues.apache.org/jira/browse/CLI-218 > Project: Commons CLI > Issue Type: New Feature > Components: CLI-1.x >Affects Versions: 1.2 >Reporter: Sven > > Often, you can invoke command with the same option multiple time. For example > java -cp test1 -cp test2 > even though the option only accepts one value. > I believe, that the majority of programs then use the last value (test2 in > this case). > However, getOptionValue() return the first value for some weired reason. > I believe, you should add a function called getLastOptionValue() (in class > CommandLine) and getLastValue() (in class Option) to allow easy access to the > last value. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLI-218) Add function similar to getOptionValue() that returns last value
Add function similar to getOptionValue() that returns last value Key: CLI-218 URL: https://issues.apache.org/jira/browse/CLI-218 Project: Commons CLI Issue Type: New Feature Components: CLI-1.x Affects Versions: 1.2 Reporter: Sven Often, you can invoke command with the same option multiple time. For example java -cp test1 -cp test2 even though the option only accepts one value. I believe, that the majority of programs then use the last value (test2 in this case). However, getOptionValue() return the first value for some weired reason. I believe, you should add a function called getLastOptionValue() (in class CommandLine) and getLastValue() (in class Option) to allow easy access to the last value. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-695) SystemUtils.IS_OS_UNIX doesn't recognize FreeBSD as a Unix system
[ https://issues.apache.org/jira/browse/LANG-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027312#comment-13027312 ] Oliver commented on LANG-695: - Hi Henri! Thanks for the comment. If it's delayed for post 3.0 anyway consider the other free BSD Unix variants: OpenBSD NetBSD > SystemUtils.IS_OS_UNIX doesn't recognize FreeBSD as a Unix system > - > > Key: LANG-695 > URL: https://issues.apache.org/jira/browse/LANG-695 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 2.6 > Environment: FreeBSD 7-STABLE >Reporter: Oliver >Priority: Minor > Fix For: 3.x > > > FreeBSD isn't recognized as Unix system in SystemUtils.IS_OS_UNIX; There > should be something like SystemUtils.IS_OS_FREEBSD, also. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
