[jira] [Commented] (DBCP-424) validateLifetime causes needless warnings about swallowed exceptions to be logged

[Eric Fialkowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBCP-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262396#comment-14262396
 ] 

Eric Fialkowski commented on DBCP-424:
--

That sounds like it will work for our needs.

> validateLifetime causes needless warnings about swallowed exceptions to be 
> logged
> -
>
> Key: DBCP-424
> URL: https://issues.apache.org/jira/browse/DBCP-424
> Project: Commons Dbcp
>  Issue Type: Improvement
>Affects Versions: 2.0
> Environment: Java 1.7, jTDS 1.2.8, Ubuntu Linux 12.04
>Reporter: Eric Fialkowski
>Priority: Minor
> Fix For: 2.1
>
>
> the validateLifetime method in PoolableConnectionFactory is causing the 
> following warning to be logged, even though it is not an exceptional case. 
> While it is not impairing functionality, we have to work around the issue.
> 2014-07-29 14:15:28.0573 WARN http-8084-52 
> org.apache.commons.dbcp2.BasicDataSource An internal object pool swallowed an 
> Exception
> java.lang.Exception: The lifetime of the connection [300,008] milliseconds 
> exceeds the maximum permitted value of [300,000] milliseconds
> at 
> org.apache.commons.dbcp2.PoolableConnectionFactory.validateLifetime(PoolableConnectionFactory.java:370)
> at 
> org.apache.commons.dbcp2.PoolableConnectionFactory.passivateObject(PoolableConnectionFactory.java:310)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.returnObject(GenericObjectPool.java:577)
> at 
> org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:171)
> 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:229)
> at 
> org.springframework.jdbc.datasource.DataSourceUtils.doCloseConnection(DataSourceUtils.java:341)
> at 
> org.springframework.jdbc.datasource.DataSourceUtils.doReleaseConnection(DataSourceUtils.java:328)
> at 
> org.springframework.jdbc.datasource.DataSourceUtils.releaseConnection(DataSourceUtils.java:294)
> at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:417)
> at 
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:468)
> at 
> org.springframework.jdbc.core.JdbcTemplate.queryForRowSet(JdbcTemplate.java:523)
> at com.ca.vm.lib.dao.ModelDao.loadJobDetails(ModelDao.java:999)
> at com.ca.vm.lib.dao.ModelDao.extractJobs(ModelDao.java:910)
> at com.ca.vm.lib.dao.ModelDao.extractJob(ModelDao.java:921)
> at com.ca.vm.lib.dao.ModelDao.loadJob(ModelDao.java:744)
> at 
> com.ca.vm.api.jobs.JobsApiLinksLoader$1.load(JobsApiLinksLoader.java:48)
> at 
> com.ca.vm.api.json.ApiLinksExpander.makeApiRequest(ApiLinksExpander.java:130)
> at 
> com.ca.vm.api.json.ApiLinksExpander.expand(ApiLinksExpander.java:114)
> at 
> com.ca.vm.api.json.ApiLinksExpander.rootExpand(ApiLinksExpander.java:65)
> at 
> com.ca.vm.api.json.ApiLinksExpander.toJson(ApiLinksExpander.java:60)
> at com.ca.vm.api.JobsResource.getJobById(JobsResource.java:283)
> at sun.reflect.GeneratedMethodAccessor317.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511)
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
> at 
> com.sun.jerse

[jira] [Commented] (DBCP-424) validateLifetime causes needless warnings about swallowed exceptions to be logged

[Phil Steitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBCP-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262387#comment-14262387
 ] 

Phil Steitz commented on DBCP-424:
--

I am inclined to fix this as follows:

1.  Add a logExpiredConnections property to BDS.
2.  Change PCF to throw a specialized exception, say 
"LifetimeExceededExeption," when connections expire.
3.  Add a boolean property (and additional constructor)  to 
SwallowedExceptionLogger to propagate the BDS property.  For backward 
compatibility, make the default value true.  Then change 
SwallowedExceptionLogger#onSwallowException to only log 
LifetimeExceededExeption when logExpiredConnections is true.

Any objections to this?

> validateLifetime causes needless warnings about swallowed exceptions to be 
> logged
> -
>
> Key: DBCP-424
> URL: https://issues.apache.org/jira/browse/DBCP-424
> Project: Commons Dbcp
>  Issue Type: Improvement
>Affects Versions: 2.0
> Environment: Java 1.7, jTDS 1.2.8, Ubuntu Linux 12.04
>Reporter: Eric Fialkowski
>Priority: Minor
> Fix For: 2.1
>
>
> the validateLifetime method in PoolableConnectionFactory is causing the 
> following warning to be logged, even though it is not an exceptional case. 
> While it is not impairing functionality, we have to work around the issue.
> 2014-07-29 14:15:28.0573 WARN http-8084-52 
> org.apache.commons.dbcp2.BasicDataSource An internal object pool swallowed an 
> Exception
> java.lang.Exception: The lifetime of the connection [300,008] milliseconds 
> exceeds the maximum permitted value of [300,000] milliseconds
> at 
> org.apache.commons.dbcp2.PoolableConnectionFactory.validateLifetime(PoolableConnectionFactory.java:370)
> at 
> org.apache.commons.dbcp2.PoolableConnectionFactory.passivateObject(PoolableConnectionFactory.java:310)
> at 
> org.apache.commons.pool2.impl.GenericObjectPool.returnObject(GenericObjectPool.java:577)
> at 
> org.apache.commons.dbcp2.PoolableConnection.close(PoolableConnection.java:171)
> 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:229)
> at 
> org.springframework.jdbc.datasource.DataSourceUtils.doCloseConnection(DataSourceUtils.java:341)
> at 
> org.springframework.jdbc.datasource.DataSourceUtils.doReleaseConnection(DataSourceUtils.java:328)
> at 
> org.springframework.jdbc.datasource.DataSourceUtils.releaseConnection(DataSourceUtils.java:294)
> at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:417)
> at 
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:468)
> at 
> org.springframework.jdbc.core.JdbcTemplate.queryForRowSet(JdbcTemplate.java:523)
> at com.ca.vm.lib.dao.ModelDao.loadJobDetails(ModelDao.java:999)
> at com.ca.vm.lib.dao.ModelDao.extractJobs(ModelDao.java:910)
> at com.ca.vm.lib.dao.ModelDao.extractJob(ModelDao.java:921)
> at com.ca.vm.lib.dao.ModelDao.loadJob(ModelDao.java:744)
> at 
> com.ca.vm.api.jobs.JobsApiLinksLoader$1.load(JobsApiLinksLoader.java:48)
> at 
> com.ca.vm.api.json.ApiLinksExpander.makeApiRequest(ApiLinksExpander.java:130)
> at 
> com.ca.vm.api.json.ApiLinksExpander.expand(ApiLinksExpander.java:114)
> at 
> com.ca.vm.api.json.ApiLinksExpander.rootExpand(ApiLinksExpander.java:65)
> at 
> com.ca.vm.api.json.ApiLinksExpander.toJson(ApiLinksExpander.java:60)
> at com.ca.vm.api.JobsResource.getJobById(JobsResource.java:283)
> at sun.reflect.GeneratedMethodAccessor317.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
> at 
>

[jira] [Commented] (DBCP-423) PoolingDataSource should implement Closeable

[Phil Steitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262378#comment-14262378
 ] 

Phil Steitz commented on DBCP-423:
--

It seems a little smelly to me to implement Closeable from java.io here.  I 
would be OK adding a close method to PoolingDataSource that properly handles 
edge cases, etc, like the close in BasicDataSource does.  Would that be 
sufficient?  Any other thoughts on this?

> PoolingDataSource should implement Closeable
> 
>
> Key: DBCP-423
> URL: https://issues.apache.org/jira/browse/DBCP-423
> Project: Commons Dbcp
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Christian Schneider
> Fix For: 2.1
>
>
> Currently PoolingDataSource only implements DataSource. 
> I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in 
> one bundle that can create a pooling DataSource.
> Then in another bundle I create DataSources based on config in 
> ConfigurationAdmin. So when the config appears I create the DataSource, when 
> the config goes away I have to destroy it.
> It is important to correctly dispose the DataSource as the pool has to be 
> closed. As I can not depend on dbcp in the bundle that destroys the 
> DataSource I currently have no simple way to destroy the DataSource.
> This is where I create the DataSource:
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
> I was able to solve it by a kind of hack. I extended the PoolingDataSource 
> with a class that supports Closeable. So from the other bundle I could check 
> if the object implements Closeable and call close.
> It would be a lot easier if PoolingDataSource would implement Closeable like 
> I did. The same is true for GenericObjectPool and the other pools. If they 
> would implement Closeable then handling them would be a lot easier.
> They already support a close method so it would be a small change.
> 
> public class CloseablePoolingDataSource extends 
> PoolingDataSource implements Closeable {
> public CloseablePoolingDataSource(ObjectPool pool) {
> super(pool);
> }
> @Override
> public void close() throws IOException {
> getPool().close();
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (POOL-245) [PATCH] Typo and remove duplicate null check

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/POOL-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262356#comment-14262356
 ] 

Bruno P. Kinoshita commented on POOL-245:
-

Thanks for taking care of the patches Mark :-) 

> [PATCH] Typo and remove duplicate null check
> 
>
> Key: POOL-245
> URL: https://issues.apache.org/jira/browse/POOL-245
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: patch, typo
> Fix For: 2.1
>
> Attachments: POOL-245.patch
>
>
> This patch fixes a trivial typo in PoolUtils javadocs, and removes a 
> duplicate null check. There is no way (besides reflection, mocking, etc) to 
> test both null checks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMMONSSITE-81) commons-build-plugin README/CONTRIBUTING.md handle multi-modules

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels updated COMMONSSITE-81:
---
Description: 
The following patch will allow the commons-build-plugin to generate the correct 
README/CONTRIBUTING.md even when we are in a multi-module scenario. 

It will especially not use artifact-id for URLs (but 
`commons-${commons.componentId}`).

This requires that the componentid does not contain "commons-" prefix (which is 
not given for the plugin itself).

There is a hack for creating a usefull maven artifact dependency. If the 
current project contains "-project" it is removed as it is asumed that the main 
artifact you want to include is not the meta-artifact. 

(This "hack" works for VFS but it is a bit ugly, thats why I did not simply 
commit it).

The patch also uses https for all the links.

BTW: for VFS the generated 2 files in the top level directory work (besides the 
download-link and apidoc).

  was:
The following patch will allow the commons-build-plugin to generate the correct 
README/CONTRIBUTING.md even when we are in a multi-module scenario. 

It will especially not use artifact-id for URLs (but 
commons-${commons.componentId}).

This requires that the componentid does not contain "commons-" prefix (which is 
not given for the plugin itself).

There is a hack for creating a usefull maven artifact dependency. If the 
current project contains "-project" it is removed as it is asumed that the main 
artifact you want to include is not the meta-artifact. 

(This "hack" works for VFS but it is a bit ugly, thats why I did not simply 
commit it).

The patch also uses https for all the links.

BTW: for VFS the generated 2 files in the top level directory work (besides the 
download-link and apidoc).


> commons-build-plugin README/CONTRIBUTING.md handle multi-modules
> 
>
> Key: COMMONSSITE-81
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-81
> Project: Commons All
>  Issue Type: Improvement
>  Components: Commons Build Plugin
>Affects Versions: 1.5-SNAPSHOT
>Reporter: Bernd Eckenfels
>Priority: Minor
>  Labels: patch
> Attachments: multi-readme.patch
>
>
> The following patch will allow the commons-build-plugin to generate the 
> correct README/CONTRIBUTING.md even when we are in a multi-module scenario. 
> It will especially not use artifact-id for URLs (but 
> `commons-${commons.componentId}`).
> This requires that the componentid does not contain "commons-" prefix (which 
> is not given for the plugin itself).
> There is a hack for creating a usefull maven artifact dependency. If the 
> current project contains "-project" it is removed as it is asumed that the 
> main artifact you want to include is not the meta-artifact. 
> (This "hack" works for VFS but it is a bit ugly, thats why I did not simply 
> commit it).
> The patch also uses https for all the links.
> BTW: for VFS the generated 2 files in the top level directory work (besides 
> the download-link and apidoc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMMONSSITE-81) commons-build-plugin README/CONTRIBUTING.md handle multi-modules

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels updated COMMONSSITE-81:
---
Attachment: multi-readme.patch

> commons-build-plugin README/CONTRIBUTING.md handle multi-modules
> 
>
> Key: COMMONSSITE-81
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-81
> Project: Commons All
>  Issue Type: Improvement
>  Components: Commons Build Plugin
>Affects Versions: 1.5-SNAPSHOT
>Reporter: Bernd Eckenfels
>Priority: Minor
>  Labels: patch
> Attachments: multi-readme.patch
>
>
> The following patch will allow the commons-build-plugin to generate the 
> correct README/CONTRIBUTING.md even when we are in a multi-module scenario. 
> It will especially not use artifact-id for URLs (but 
> commons-${commons.componentId}).
> This requires that the componentid does not contain "commons-" prefix (which 
> is not given for the plugin itself).
> There is a hack for creating a usefull maven artifact dependency. If the 
> current project contains "-project" it is removed as it is asumed that the 
> main artifact you want to include is not the meta-artifact. 
> (This "hack" works for VFS but it is a bit ugly, thats why I did not simply 
> commit it).
> The patch also uses https for all the links.
> BTW: for VFS the generated 2 files in the top level directory work (besides 
> the download-link and apidoc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMMONSSITE-81) commons-build-plugin README/CONTRIBUTING.md handle multi-modules

[Bernd Eckenfels (JIRA)]

Bernd Eckenfels created COMMONSSITE-81:
--

 Summary: commons-build-plugin README/CONTRIBUTING.md handle 
multi-modules
 Key: COMMONSSITE-81
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-81
 Project: Commons All
  Issue Type: Improvement
  Components: Commons Build Plugin
Affects Versions: 1.5-SNAPSHOT
Reporter: Bernd Eckenfels
Priority: Minor


The following patch will allow the commons-build-plugin to generate the correct 
README/CONTRIBUTING.md even when we are in a multi-module scenario. 

It will especially not use artifact-id for URLs (but 
commons-${commons.componentId}).

This requires that the componentid does not contain "commons-" prefix (which is 
not given for the plugin itself).

There is a hack for creating a usefull maven artifact dependency. If the 
current project contains "-project" it is removed as it is asumed that the main 
artifact you want to include is not the meta-artifact. 

(This "hack" works for VFS but it is a bit ugly, thats why I did not simply 
commit it).

The patch also uses https for all the links.

BTW: for VFS the generated 2 files in the top level directory work (besides the 
download-link and apidoc).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (POOL-282) CLONE - Support AbandonedConfig in SharedPoolDataSource

[Phil Steitz (JIRA)]

[ 
https://issues.apache.org/jira/browse/POOL-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262339#comment-14262339
 ] 

Phil Steitz commented on POOL-282:
--

The pool request here is to have GenericKeyedObjectPool support abandoned 
object tracking and cleanup.

> CLONE - Support AbandonedConfig in SharedPoolDataSource
> ---
>
> Key: POOL-282
> URL: https://issues.apache.org/jira/browse/POOL-282
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.0, 2.1, 2.2, 2.3
> Environment: Linux and Java 1.6
>Reporter: Michael Kerr
>Priority: Minor
>  Labels: features
>
> BasicDataSource has support for AbandonedConfig
> SharedPoolDataSource does not currently support reclaiming abandoned 
> connections.
> It would be helpful if the user can extend the underlying connection pool to 
> add features like abandoned connection management.  This is possible with 
> BasicDataSource.
> Currently the only solution is to extend classes or replace classes in the 
> Apache package namespace.
> Thanks for looking,
> Michael



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NET-566) UnixFTPEntryParser Drops Leading Spaces from File Names

[Gary Russell (JIRA)]

Gary Russell created NET-566:


 Summary: UnixFTPEntryParser Drops Leading Spaces from File Names
 Key: NET-566
 URL: https://issues.apache.org/jira/browse/NET-566
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.3
 Environment: OSX client, Linux ftpd
Reporter: Gary Russell


The {{UnixFTPEntryParser}} [regular expression | 
http://svn.apache.org/viewvc/commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/parser/UnixFTPEntryParser.java?view=markup]
 (line 106) consumes all spaces between the timestamp and the file name.

The {{FTPFile.name}} property ends up getting a value with stripped leading 
spaces.

Reported by Spring Integration user at https://jira.spring.io/browse/INT-3591



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-218) Does borrowObject block?

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-218.


> Does borrowObject block?
> 
>
> Key: POOL-218
> URL: https://issues.apache.org/jira/browse/POOL-218
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.6
> Environment: Mac lion and java 1.6
>Reporter: Gautam
>Priority: Trivial
>
> I'm trying to pool some objects and share them but I noticed blocking in the 
> threads.  I'm a bit new to Java so not sure if this is a problem with my lack 
> of experience or something specific to pools. Here's some code that 
> replicates the problem(Create 10 threads and share 20 objects, do this in a 
> long loop so you can catch the blocking). If you profile it, you'll notice 
> that borrowObject seems to be blocking the thread.  So the question is, is 
> this normal behavior or am I doing something wrong?
> {code}
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import org.apache.commons.pool.BasePoolableObjectFactory;
> import org.apache.commons.pool.ObjectPool;
> import org.apache.commons.pool.impl.GenericObjectPool;
> public class main{
> public static void main(String[] a){
> ObjectPool fpool = new GenericObjectPool(new 
> FooPoolableObjectFactory(), 20);
> ExecutorService tpool = Executors.newFixedThreadPool(10);
> 
> for(int i = 0; i < 9; ++i){
> tpool.submit(new FooWorker(fpool));
> }
> }
> }
> class Foo{
> private static int pk = 0;
> private int count = 0;
> public final int id;
> 
> public Foo(){
> id = pk++;
> }
> 
> public int increment(){
> return ++count;
> }
> }
> class FooWorker implements Runnable{
> private ObjectPool fpool;
> 
> public FooWorker(ObjectPool fpool){
> this.fpool = fpool;
> }
> 
> @Override
> public void run(){
> Foo foo = null;
> try{
> foo = fpool.borrowObject();
> //System.out.println(foo.id + ": " + foo.increment());
> }
> catch(Exception e){
> e.printStackTrace();
> }
> finally{
> // This is done in a finally block to ensure the object is 
> returned to the pool
> if(foo != null){
> try{
> fpool.returnObject(foo);
> }
> catch(Exception e){
> e.printStackTrace();
> }
> }
> }
> }
> }
> class FooPoolableObjectFactory extends BasePoolableObjectFactory{
> 
> @Override
> public Foo makeObject() throws Exception{
> return new Foo();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-246) [PATCH] Follow same pattern in ErodingKeyedObjectPool#toString as in other pool objects

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-246.


> [PATCH] Follow same pattern in ErodingKeyedObjectPool#toString as in other 
> pool objects
> ---
>
> Key: POOL-246
> URL: https://issues.apache.org/jira/browse/POOL-246
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: patch
> Fix For: 2.1
>
> Attachments: POOL-246.patch
>
>
> Hello!
> In ErodingObjectPool, the toString method outputs: 
> ErodingObjectPool{factor=$FACTOR, pool=$POOL}
> And in ErodingPerKeyKeyedObjectPool it outputs: 
> ErodingPerKeyKeyedObjectPool{factor=, keyedPool=$POOL}
> However, in ErodingKeyedObjectPool, the factor has a different prefix: 
> ErodingKeyedObjectPool{erodingFactor=$FACTOR, keyedPool=$POOL}
> This proposed patch follows the same pattern as in the aforementioned pools 
> and changes ErodingKeyedObjectPool#toString.
> Please, note that POOL-244 contains tests that may fail due to this change, 
> so during the merge it may be good to take a look at 
> TestPoolUtils#testErodingPoolKeyedObjectPoolDefaultFactor to avoid build 
> errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-245) [PATCH] Typo and remove duplicate null check

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-245.


> [PATCH] Typo and remove duplicate null check
> 
>
> Key: POOL-245
> URL: https://issues.apache.org/jira/browse/POOL-245
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: patch, typo
> Fix For: 2.1
>
> Attachments: POOL-245.patch
>
>
> This patch fixes a trivial typo in PoolUtils javadocs, and removes a 
> duplicate null check. There is no way (besides reflection, mocking, etc) to 
> test both null checks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-241) [PATCH] Add more tests to [pool]

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-241.


> [PATCH] Add more tests to [pool]
> 
>
> Key: POOL-241
> URL: https://issues.apache.org/jira/browse/POOL-241
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: coverage, patch, tests
> Fix For: 2.1
>
> Attachments: POOL-241.patch
>
>
> Hello, I had some spare time today and decided to add more tests to some 
> Apache Commons components. 
> Hopefully someone else will be able to review the new tests and see if there 
> is some use for these tests in [pool]. Applying the whole patch would 
> increase the coverage, specially in classes with less than 50% of coverage.
> Hope that helps, 
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-244) [PATCH] Add more tests to [pool]

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-244.


> [PATCH] Add more tests to [pool]
> 
>
> Key: POOL-244
> URL: https://issues.apache.org/jira/browse/POOL-244
> Project: Commons Pool
>  Issue Type: Test
>Reporter: Bruno P. Kinoshita
>Priority: Trivial
>  Labels: coverage, patch, tests
> Fix For: 2.1
>
> Attachments: POOL-244.patch
>
>
> Hi! 
> I read a new version of [pool] was being prepared to be released and decided 
> to chime in and add a few more tests. 
> With these new tests, I believe the line coverage is above 70% is almost all 
> the inner/classes but one that I thought wasn't worth writing more tests. 
> In future dev cycles I hope to be able to increase the branch coverage to 
> somewhere near 70% too, as well as fix some of the TODO tasks in the test 
> code.
> I found a few trivial things that could be changed I think (typos, 
> unreachable if's and naming inconsistencies) but I'll create separate issues 
> for each one.
> Please, feel free to massage the code as much as needed or drop any parts if 
> needed.
> Hope that helps, 
> Bruno



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-279) Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-279.


> Thread concurrency issue in DefaultPooledObject.getIdleTimeMillis()
> ---
>
> Key: POOL-279
> URL: https://issues.apache.org/jira/browse/POOL-279
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Jacopo Cappellato
>Priority: Minor
> Fix For: 2.3
>
> Attachments: POOL-279-unit-test.patch, POOL-279.patch, 
> POOL-279.patch, POOL-279.patch, POOL-279.patch
>
>
> Under unlucky thread concurrency the getIdleTimeMillis() method of 
> DefaultPooledObject can return a negative value.
> I have attached a Junit test that fails most of the times and a simple fix, 
> that doesn't use synchronization: with this fix the Junit test always succeed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-121) Provide thread name for EvcitionTimer

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-121.


> Provide thread name for EvcitionTimer
> -
>
> Key: POOL-121
> URL: https://issues.apache.org/jira/browse/POOL-121
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.3, 1.4
>Reporter: Christoph Kutzinski
>Priority: Trivial
> Fix For: 2.0
>
>
> When taking thread dumps and while debugging, I always like when each thread 
> has a speaking name. Therefore I suggest that Pool's EvictionTimer should 
> have a name, too.
> E.g.:
> instead of
>  _timer = new Timer(true);
> use
> _timer = new Timer("commons-pool-EvictionTimer", true);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-182) Issues with org.apache.commons.pool2.performance. PerformanceTest

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-182.


> Issues with org.apache.commons.pool2.performance. PerformanceTest
> -
>
> Key: POOL-182
> URL: https://issues.apache.org/jira/browse/POOL-182
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Zoltan Farkas
>Priority: Trivial
> Fix For: 2.0
>
> Attachments: PerformanceTest.patch
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
>  the use volatiles : waiting,complete,totalBorrowTime, totalReturnTime, 
> nrSamples
>  is not correct.
>  for ex the following totalBorrowTime += borrowTime is not atomic resulting 
> in a
>  race condition.
>  one way to fix this is using the java.util.concurent Atomic variants or even
>  better,
>  make these variables members of MyThread and aggregate them at the end of the
>  test,
>  this way there will be no need to use Atomic and thus increasing efficiency, 
> and
>  accuracy of the test of the test.
>  also:
>  private boolean start;
>  needs to be volatile, due to visibility issue.
>  (when updating start other threads might not pick up the value)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-99) Test for idle time exceeded in borrowObject

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-99.
---

> Test  for idle time exceeded in borrowObject
> 
>
> Key: POOL-99
> URL: https://issues.apache.org/jira/browse/POOL-99
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Rob Eamon
>Priority: Minor
>
> For GenericObjectPool, the evictor thread performs a calculation to determine 
> if an idle object as "expired." If it has, the object is destroyed.
> Would like borrowObject to perform the same test and destroy behavior.
> I explored using the testOnBorrow facility but the time that the object went 
> idle is not available. Only the pool has access to the ObjectTimestampPair 
> object that is used to record the time that the object was placed in the 
> pool. I explored placing a timestamp in the pooled object and can do that but 
> it would seem better if the pool managed that test itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-98) Make GenericObjectPool better extensible

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-98.
---

> Make GenericObjectPool better extensible
> 
>
> Key: POOL-98
> URL: https://issues.apache.org/jira/browse/POOL-98
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Henning Schmiedehausen
>Assignee: Mark Thomas
>Priority: Minor
> Fix For: 2.0
>
>
> The current implementation of GenericObjectPool encapsulates the _pool
> object and there is no way to get it directly, which makes some things
> like JMX pool monitoring a bit awkward.
> Would it be possible to either make _pool protected or add a method
> protected Collection getInternalPool() {
> return _pool;
> }
> or something like that to the GenericObjectPool implementation (and
> probably others, but that is the one that bites me most... :-) )
> This would make extending the GenericObjectPool much easier.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-83) Support Java 1.5 Generics

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-83.
---

> Support Java 1.5 Generics
> -
>
> Key: POOL-83
> URL: https://issues.apache.org/jira/browse/POOL-83
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Sam Berlin
>Assignee: Simone Tripodi
>Priority: Minor
> Fix For: 2.0
>
> Attachments: generics.txt
>
>
> It would be nice if there was a build that supported Java 1.5's Generics.  
> This probably isn't possible to include in the regular distribution, since 
> Commons-Pool probably wants to maintain compatability with older versions of 
> Java, but generics are highly desirable, especially for a project such as 
> pool.  I have spent the day or so adding support to it in our CVS repository 
> (viewable at https://www.limewire.org/fisheye/browse/misc/commons-pool ). 
> I'll attach the patch to generify the code, if you decide that it is possible 
> to include in the main distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-134) Parameterize the maxWait time to be per borrow call

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-134.


> Parameterize the maxWait time to be per borrow call
> ---
>
> Key: POOL-134
> URL: https://issues.apache.org/jira/browse/POOL-134
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.4
> Environment: JRE 1.4.x
>Reporter: David Meibusch
>Assignee: Mark Thomas
>Priority: Minor
> Fix For: 2.0
>
>
> Use case: 
> The pool is being used to pool connections in a mid-tier system to a backend 
> system.
> Client requests to the system have a configured timeout specified as an 
> elapsed time with respect to the client application. 
> Requests may spend some elapsed time in internal work queues and/or may 
> borrow connections multiple times to service the single request.
> When calling the borrowObject method the mid tier system requires the wait 
> time to be only a portion of request time remaining.
> The maxWait time for the GenericObjectPool is currently a global value for 
> all borrowObject operations.
> The current implementation requires only minor changes to support a per 
> borrowObject maxTime.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-200) GOP/GKOP don't consistently use getters to access fields

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-200.


> GOP/GKOP don't consistently use getters to access fields
> 
>
> Key: POOL-200
> URL: https://issues.apache.org/jira/browse/POOL-200
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.0
>
>
> The GOP/GKOP classes generally always use getters to read the values of local 
> fields, e.g. maxIdle.
> However, some fields are accessed directly.
> The code should be consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-203) GenericKeyedObjectPool.ObjectDeque could be better encapsulated

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-203.


> GenericKeyedObjectPool.ObjectDeque could be better encapsulated
> ---
>
> Key: POOL-203
> URL: https://issues.apache.org/jira/browse/POOL-203
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
>
> GenericKeyedObjectPool.ObjectDeque is currently basically just a collection 
> of Objects with getters.
> This necessarily exposes the implementation, and makes adding invariant 
> checks a lot harder - e.g. ensuring createCount >=0.
> The suggestion is to replace the getters with functional methods, for example:
> objectDeque.getCreateCount().incrementAndGet() => objectDeque.createdEntry();
> objectDeque.getAllObjects().put(t, p); => objectDeque.addNew(t, p);
> objectDeque.getIdleObjects().addFirst(p)/addLast(p) => 
> objectDeque.idle(p,getLifo())
> The new methods could include assertions for invariants, and adding debug 
> would be a doddle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-173) Better config without duplication.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-173.


> Better config without duplication.
> --
>
> Key: POOL-173
> URL: https://issues.apache.org/jira/browse/POOL-173
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Gary Gregory
>Priority: Minor
> Fix For: 2.0
>
> Attachments: commons-pool2-configExisting.dia, 
> commons-pool2-configExisting.png, genericObjectPoolConfig.patch, 
> pool173-better_config_without_duplication.diff, pool2config.diff
>
>
> There is code duplication in configuration code.
> I'd like to track an experiment here.
> > -Original Message-
> > From: Gary Gregory [mailto:ggreg...@seagullsoftware.com]
> > Sent: Wednesday, October 20, 2010 10:44
> > To: Commons Developers List
> > Subject: RE: [pool] Reusing Config
> > 
> > In the same department, I see the following ivars:
> > 
> > lifo : boolean
> > maxActive : int
> > maxIdle : int
> > maxTotal : int
> > maxWait : long
> > minEvictableIdleTimeMillis : long
> > minIdle : int
> > numTestsPerEvictionRun : int
> > testOnBorrow : boolean
> > testOnReturn : boolean
> > testWhileIdle : boolean
> > timeBetweenEvictionRunsMillis : long
> > whenExhaustedAction : WhenExhaustedAction
> > 
> > defined in four classes:
> > 
> > GenericKeyedObjectPool
> > GenericKeyedObjectPoolFactory
> > GenericObjectPool
> > GenericObjectPoolFactory
> > 
> > Which feels to me like a missed opportunity to avoid duplication.
> > 
> > Is making one ivar private or final or volatile be applied to all four
> > classes?
> > 
> > We could:
> > 
> > Use a config object instead of the 13 ivars.
> > Or a common superclass then we can consider if it should hold the ivar list 
> > or
> > a Config object.
> > 
> > Would it be too weird to have a common super class for BaseObjectPool and
> > BasePoolableObjectFactory for example?
> > 
> > Gary Gregory
> > Senior Software Engineer
> > Rocket Software
> > 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
> > Tel: +1.404.760.1560
> > Email: ggreg...@seagullsoftware.com
> > Web: seagull.rocketsoftware.com
> > 
> > 
> > 
> > > -Original Message-
> > > From: Gary Gregory [mailto:ggreg...@seagullsoftware.com]
> > > Sent: Wednesday, October 20, 2010 10:29
> > > To: Commons Developers List
> > > Subject: [pool] Reusing Config
> > >
> > > Hi All:
> > >
> > > I think this came up recently. Any thoughts or plans on extracting the
> > Config
> > > class out of GenericKeyedObjectPool and GenericObjectPool so it can be
> > reused.
> > > The constants for default values could then also be moved to Config.
> > > Gary Gregory
> > > Senior Software Engineer
> > > Rocket Software
> > > 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA
> > > Tel: +1.404.760.1560
> > > Email: ggreg...@seagullsoftware.com
> > > Web: seagull.rocketsoftware.com
> > >
> > 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-204) GKOP encapsulate poolMap/poolKeyList to ensure invariants?

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-204.


> GKOP encapsulate poolMap/poolKeyList to ensure invariants?
> --
>
> Key: POOL-204
> URL: https://issues.apache.org/jira/browse/POOL-204
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Sebb
>Priority: Minor
>
> In GKOP, poolMap and poolKeyList must be kept in step otherwise "bad things 
> will happen!".
> Might be worth considering encapsulating the data structures in a private 
> class that ensures this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-233) Borrow specific object from Pool

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-233.


> Borrow specific object from Pool
> 
>
> Key: POOL-233
> URL: https://issues.apache.org/jira/browse/POOL-233
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.6
>Reporter: Ankur Raiyani
>Assignee: Simone Tripodi
>Priority: Minor
>  Labels: common-pool
>
> Hi,
> I am using common pools to hold session objects of web service.
> The web service provider has asynchronous login service. So, in immediate 
> response of login request it returns blank token.
> The actual Session Token is received on post back listener URL and at this 
> time i need to get the object from pool and update it with session token.
> That is the reason of this enhancement request. So, that i can borrow 
> specific object by its id or some unique property and update its status and 
> release it.
> Please let me know if any further clarification is required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-226) GenericKeyedObjectPool.ObjectTimestampPair fields could be made final without breaking compat?

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-226.


> GenericKeyedObjectPool.ObjectTimestampPair fields could be made final without 
> breaking compat?
> --
>
> Key: POOL-226
> URL: https://issues.apache.org/jira/browse/POOL-226
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 1.6.1
>
>
> The package protected static class GenericKeyedObjectPool.ObjectTimestampPair 
> contains two fields which are currently deprecated, pending making them final 
> and private.
> Since the fields are package protected, surely they should only be used by 
> Commons Pool code? Does it make sense that any external code would use the 
> fields? 
> Indeed can they be used?
> If the fields cannot legitimately be used by 3rd party code, then surely 
> there's no need to wait for a major release to change them?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-216) GenericKeyedObjectPool.ensureMinIdle(K) does not need to check getMinIdlePerKey()

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-216.


> GenericKeyedObjectPool.ensureMinIdle(K) does not need to check 
> getMinIdlePerKey()
> -
>
> Key: POOL-216
> URL: https://issues.apache.org/jira/browse/POOL-216
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Sebb
>Priority: Minor
> Fix For: 2.0
>
>
> The private method GenericKeyedObjectPool.ensureMinIdle(K) checks 
> getMinIdlePerKey().
> However, when called by ensureMinIdle(void), this check has already been done.
> The private method is only otherwise called by preparePool(K), so the check 
> could be moved there.
> This would eliminate one extra check per key when executing the protected 
> ensureMinIdle() method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-228) Unit test failure in TestGenericObjectPoolClassLoaders

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-228.


> Unit test failure in TestGenericObjectPoolClassLoaders
> --
>
> Key: POOL-228
> URL: https://issues.apache.org/jira/browse/POOL-228
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Liviu Tudor
>Priority: Minor
>  Labels: junit
>
> Following error encountered when running unit tests:
> {noformat}
> Results :
> Failed tests:   
> testContextClassLoader(org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders):
>  Wrong number of idle objects in pool1 expected:<1> but was:<0>
> Tests run: 263, Failures: 1, Errors: 0, Skipped: 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-249) Javadoc 1.8.0 fixes

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-249.


> Javadoc 1.8.0 fixes
> ---
>
> Key: POOL-249
> URL: https://issues.apache.org/jira/browse/POOL-249
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Ville Skyttä
>Priority: Minor
>  Labels: patch
> Fix For: 2.2
>
> Attachments: 0001-Javadoc-1.8.0-fixes.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-260) start evictor with getTimeBetweenEvictionRunsMillis() in GenericKeyedObjectPool constructor.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-260.


> start evictor with getTimeBetweenEvictionRunsMillis()  in 
> GenericKeyedObjectPool constructor. 
> --
>
> Key: POOL-260
> URL: https://issues.apache.org/jira/browse/POOL-260
> Project: Commons Pool
>  Issue Type: Wish
>Affects Versions: 2.2
>Reporter: Yunfeng
>Priority: Minor
>
> I have set the TimeBetweenEvictionRunsMillis but the evict() desn't run on 
> time.
> pc.setTimeBetweenEvictionRunsMillis(1000 * 12);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-262) Make GOP/GKOP fairness configurable

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-262.


> 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.0, 2.1, 2.2
>Reporter: Phil Steitz
>Priority: Minor
> Fix For: 2.3
>
>
> 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.3.4#6332)

[jira] [Resolved] (LANG-1080) Add NoClassNameToStringStyle implementation of ToStringStyle

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter resolved LANG-1080.
---
Resolution: Fixed

{code}
$ svn ci -m "LANG-1080: add NoClassNameToStringStyle implementation of 
ToStringStyle. This closes #40 from github. Thanks to Innokenty Shuvalov."
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
Adding 
src/test/java/org/apache/commons/lang3/builder/NoClassNameToStringStyleTest.java
Transmitting file data ...
Committed revision 1648730.
{code}

> Add NoClassNameToStringStyle implementation of ToStringStyle
> 
>
> Key: LANG-1080
> URL: https://issues.apache.org/jira/browse/LANG-1080
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.builder.*
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 3.4
>
>
> Placeholder ticket for github pull requests 
> https://github.com/apache/commons-lang/pull/17 and 
> https://github.com/apache/commons-lang/pull/40.
> {quote}
> Using the example from ToStringBuilder, the output would look like this:
> {code}
> [name=John Doe,age=33,smoker=false]
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-183) potential new method for interface ObjectPool: returnAndValidateObject

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-183.


> potential new method for interface ObjectPool: returnAndValidateObject
> -
>
> Key: POOL-183
> URL: https://issues.apache.org/jira/browse/POOL-183
> Project: Commons Pool
>  Issue Type: New Feature
>Affects Versions: 2.0
>Reporter: Zoltan Farkas
>Priority: Minor
> Fix For: 2.0
>
>
> Would it be possible to add a method:
> void returnAndValidateObject(T obj) throws Exception
> In general I was thinking of the following use case:
> Object o = pool.borrowObject();
> try
> {
> .
> o.doStuff();
> .
> pool.returnObject(o);
> }
> catch(Exception e)
> {
> // not sure what the cause is, let's make sure o is valid.
> pool.returnAndValidateObject(o);
> }
> the reason is that validation in general is an expensive operation, and 
> enabling 
> it all the time is inpractical.
> any thoughts ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1080) Add NoClassNameToStringStyle implementation of ToStringStyle

[Benedikt Ritter (JIRA)]

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

Benedikt Ritter updated LANG-1080:
--
Component/s: lang.builder.*

> Add NoClassNameToStringStyle implementation of ToStringStyle
> 
>
> Key: LANG-1080
> URL: https://issues.apache.org/jira/browse/LANG-1080
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.builder.*
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 3.4
>
>
> Placeholder ticket for github pull requests 
> https://github.com/apache/commons-lang/pull/17 and 
> https://github.com/apache/commons-lang/pull/40.
> {quote}
> Using the example from ToStringBuilder, the output would look like this:
> {code}
> [name=John Doe,age=33,smoker=false]
> {code}
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-100) Possibiblity to define eviction policies

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-100.


> Possibiblity to define eviction policies
> 
>
> Key: POOL-100
> URL: https://issues.apache.org/jira/browse/POOL-100
> Project: Commons Pool
>  Issue Type: New Feature
> Environment: N/A
>Reporter: David J. M. Karlsen
> Fix For: 2.0
>
>
> It would be nice to be able to define eviction policies, including specifying 
> a maximum age (since creation / instanciation) for objects.
> By doing this KeyedObjectPool could supply fresh objects from makeObject( 
> Object key ) if data has changed in back-end.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-103) Tracing borrowed objects

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-103.


> Tracing borrowed objects
> 
>
> Key: POOL-103
> URL: https://issues.apache.org/jira/browse/POOL-103
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Lisen Mu
> Fix For: 2.0
>
>
> Once an object is borrowed from a GenericObjectPool, it could be 
> returnObject()-ed once or invalidateObject()-ed once, but not both.
> However, in my working environment, people often tend to write code like this:
> MyObject mo = null;
> try{
>   mo = myPool.borrowObject();
> }catch(Exception e){
>   myPool.destoryObject(mo);
> }finally{
>   if(mo != null){
>   myPool.returnObject(mo);
>   }
> }
> In this case, _numActive in GenericObjectPool would be decreased twice once 
> an Exception is thrown.
> So eachtime I use GenericObjectPool, I always wrap the pool like this:
> class MyPool extends GenericObjectPool{
> HashSet borrowed = new HashSet();
>   public synchronized Object borrowObject() throws Exception {
>   Object ret = null;
>   ret = super.borrowObject();
>   if (ret != null) {
>   borrowed.add(ret);
>   }
>   return ret;
>   }
>   public synchronized void invalidateObject(MyObject mo) {
>   if(borrowed.contains(mo)){
>   borrowed.remove(mo);
>   super.invalidateObject(mo);
>   }
>   }
>   public synchronized void returnObject(Object obj) throws Exception {
>   if (borrowed.contains(obj)) {
>   borrowed.remove(obj);
>   super.returnObject(obj);
>   }
>   }
> }
> So the inner counter _numActive would not get corrupted due to incorrect call 
> to returnObject() or invalidateObject().
> I wonder if this feature could be included into the mighty commons-pool 
> library to make this class completely FOOL proof  :)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-104) Incorrect behavior for returnObject function.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-104.


> Incorrect behavior for returnObject function.
> -
>
> Key: POOL-104
> URL: https://issues.apache.org/jira/browse/POOL-104
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: Windows XP + Eclipse3.2 + JDK1.5
>Reporter: Phenix Huang
>
> Bussiness Needs
> I want to implement a special pool which can restore the active item 
> automatically after over time. After the item had been restored by the pool, 
> if client still return the object to pool(client still keep the reference 
> thought the object had been passative) , the issue will occurs.
> Test Case :
> 1. Client borrow an object from pool.
> 2. Client return the object to the pool. The active num will substract 1 and 
> idle num will plus 1.
> 3. If the client return the same object to the pool many times, the active 
> num might be negative.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-150) GenericKeyedObjectPool.preparePool does not throw an exception if supplied factory is null

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-150.


> GenericKeyedObjectPool.preparePool does not throw an exception if supplied 
> factory is null
> --
>
> Key: POOL-150
> URL: https://issues.apache.org/jira/browse/POOL-150
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: Java 5
>Reporter: VIJAY KUMAR
> Fix For: 2.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> GenericKeyedObjectPool.preparePool  doesnot throw an exception if supplied 
> factory is null. 
> GenericKeyedObjectPool.preparePool invokes ensureMinIdle() if 
> populateImmediately is true and GenericKeyedObjectPool.ensureMinIdle() 
> invokes GenericKeyedObjectPool.addObject() which throws an 
> IllegalStateException if factory is null but this exception does not throw 
> further in GenericKeyedObjectPool.preparePool.
> Catch block of  GenericKeyedObjectPool..preparePool is empty.
> public synchronized void preparePool(Object key, boolean populateImmediately) 
> {
>   ObjectQueue pool = (ObjectQueue)(_poolMap.get(key));
>   System.out.println(this.getClass().getName()+".preparePool() pool  
> ["+pool +"]");
> if (null == pool) {
> pool = new ObjectQueue();
> _poolMap.put(key,pool);
> _poolList.add(key);
> }
> if (populateImmediately) {
> try {
> // Create the pooled objects
>   System.out.println(this.getClass().getName()+".preparePool() 
> Create the pooled objects ");
> ensureMinIdle(key);
> }
> catch (Exception e) {
> //Do nothing
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-140) Rethink synchronisation strategy

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-140.


> Rethink synchronisation strategy
> 
>
> Key: POOL-140
> URL: https://issues.apache.org/jira/browse/POOL-140
> Project: Commons Pool
>  Issue Type: Task
>Reporter: Sebb
> Fix For: 2.0
>
>
> Holding place for items related to synch. that need to be addressed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-142) Swallowing exceptions throw by factory destroy() methods can hide genuine issues

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-142.


> Swallowing exceptions throw by factory destroy() methods can hide genuine 
> issues
> 
>
> Key: POOL-142
> URL: https://issues.apache.org/jira/browse/POOL-142
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Mark Thomas
> Fix For: 2.0
>
>
> Swallowing all factory exceptions prevents the factory indicating to the pool 
> that there is an issue. For example, attempting to destroy an object twice 
> may indicate a bug in the pool code. The factory exception policy needs to be 
> reviewed. If changed this will be an API change to needs to wait until 2.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-148) borrowObject should return the exception thrown by validateObject when throwing an Exception to let Exceptions be handled at a higher level

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-148.


> borrowObject should return the exception thrown by validateObject when 
> throwing an Exception to let Exceptions be handled at a higher level
> ---
>
> Key: POOL-148
> URL: https://issues.apache.org/jira/browse/POOL-148
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.2
> Environment: All
>Reporter: Monsieur EDI
>Assignee: Mark Thomas
> Fix For: 2.0
>
>
> public Object borrowObject() throws Exception {
> ...
> try {
> ...
> if(newlyCreated) {
> throw new NoSuchElementException("Could not create a 
> validated object, cause: " + e.getMessage());
> }
> SHOULD BE CHANGED TO :
> if(newlyCreated) {
> throw new Exception("Could not create a validated 
> object", e);
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (LANG-1080) Add NoClassNameToStringStyle implementation of ToStringStyle

[Benedikt Ritter (JIRA)]

Benedikt Ritter created LANG-1080:
-

 Summary: Add NoClassNameToStringStyle implementation of 
ToStringStyle
 Key: LANG-1080
 URL: https://issues.apache.org/jira/browse/LANG-1080
 Project: Commons Lang
  Issue Type: New Feature
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
 Fix For: 3.4


Placeholder ticket for github pull requests 
https://github.com/apache/commons-lang/pull/17 and 
https://github.com/apache/commons-lang/pull/40.

{quote}
Using the example from ToStringBuilder, the output would look like this:

{code}
[name=John Doe,age=33,smoker=false]
{code}
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-131) Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log errors about passivation/destroying

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-131.


> Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log 
> errors about passivation/destroying
> 
>
> Key: POOL-131
> URL: https://issues.apache.org/jira/browse/POOL-131
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.4
> Environment: Spring Framework JTA transaction Manager + jBossTS + DBCP
>Reporter: Mauro Molinari
> Fix For: 2.0
>
>
> In our environment it happens the following. Suppose our code has a bug and 
> does not release a connection previously obtained from DBCP. 
> Suppose a JTA transaction is in progress when this happens.
> When trying to commit this transaction, Spring has a guard that realizes that 
> the owner of that transaction is in some way "dead", so it tries to close the 
> connection before committing (I think this is a problem, however, let's go 
> on). Closing the connection makes DBCP/Pool call returnObject on the 
> GenericObjectPool, then addObjectToPool and, at last, passivateObject. As the 
> connection is neither in auto-commit mode nor read-only, passivateObject 
> issues a rollback on the connection but then jBossTS throws a SQLException 
> saying that it is not allowed to issue a rollback on an underlying connection 
> while a higher level JTA transaction is in progress. This exception is caught 
> by returnObject and it is completely lost, because returnObject does not log 
> it, nor it forwards it upward.
> The final result is that:
> - the connection is not given back to the Pool, because of the exception
> - however, the physical underlying connection to the DBMS remains open
> => we have a connection leak, without any proof of it (no exceptions are 
> logged in any way)
> To get to these results I had to carefully debug my code. It would have been 
> very easier if Pool logged exceptions thrown during passivation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-155) ObjectPool.invalidateObject(object) should throw an Exception if object is null

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-155.


> ObjectPool.invalidateObject(object) should throw an Exception if object is 
> null
> ---
>
> Key: POOL-155
> URL: https://issues.apache.org/jira/browse/POOL-155
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.0, 1.0.1, 1.1, 1.2, 1.3, 1.4, 1.5, 1.5.1, 1.5.2, 
> 1.5.3, 1.5.4
>Reporter: Sebb
> Fix For: 2.0
>
>
> ObjectPool.invalidateObject(object) should throw an Exception if object is 
> null, otherwise the numActive count can get out of synch.
> It's easy to do this by mistake, see:
> http://markmail.org/thread/ya22ihmghejbfzme
> Also, the documentation for ObjectPool needs to be updated to clarify that 
> invalidateObject should only be called if the object failed, not the borrow.
> [I'll do this shortly]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-159) GenericObjectPool: Add a getNumWaiters() method for monitoring purposes

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-159.


> GenericObjectPool: Add a getNumWaiters() method for monitoring purposes
> ---
>
> Key: POOL-159
> URL: https://issues.apache.org/jira/browse/POOL-159
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4
>Reporter: Mike Muller
>  Labels: monitoring
> Fix For: 2.0
>
>
> I would like to be able to determine the number of threads waiting to obtain 
> an object from the pool for monitoring purposes.  This would be most 
> applicable when the WHEN_EXHAUSTED_BLOCK option is used.  I propose the 
> following method:
> /**
>  * Return the number of threads currently waiting for an object from this 
> pool.
>  *
>  * @return the number of threads currently waiting for an object from 
> this pool
>  */
> public synchronized int getNumWaiters() {
> return _allocateQueue.size();
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-213) _numActive can go negative

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-213.


> _numActive can go negative
> --
>
> Key: POOL-213
> URL: https://issues.apache.org/jira/browse/POOL-213
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Mark Mindenhall
> Fix For: 2.0
>
>
> I'm working on a project that uses Hector (Cassandra client).  Hector uses 
> commons-pool (we're using 1.5.4) to pool connections to hosts within a 
> Cassandra cluster.  Hector provides a JMX MBean that exposes a "NumActive" 
> property, which is the cumulative call to retrieve numActive from all of the 
> individual connection pools.  When querying this property via JMS on our 
> production servers, we often see negative values.  For example, on a server 
> that has three connection pools, the "NumActive" property reported was -3899.
> I know this issue has been reported before (POOL-29), and was supposedly 
> fixed.  The fix discussed there was to merely check the value of _numActive 
> to prevent it from going negative.  However, that does not fix the real 
> problem here, which is that it is possible to decrement _numActive more than 
> once for each activated object.  
> For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), 
> it would be possible to do the following:
> 1)  Create a pool with 10 objects.
> 2)  Borrow all 10 objects from the pool.
> 3)  Call getNumActive (returns 10).
> 4)  Call invalidateObject for ONE of the objects 11 times.
> 5)  Call getNumActive (returns -1).
> The invalidateObject method calls the _factory to destroy the object, and 
> subsequent calls to destroy the same object may or may not result in an 
> exception.  Regardless, _numActive is decremented within a finally block, and 
> therefore would always be decremented even if the object had already been 
> invalidated and destroyed.
> I'd like to suggest using a HashSet instead of a counter to keep track of 
> active objects.  If borrowing an object added it to a HashSet, and returning 
> or invaliding the object removed it from the HashSet (subsequent removes 
> would be no-ops), the example given above would not result in an incorrect 
> value when getNumActive is called (it would just return the current size of 
> the HashSet).
> Note that although unrelated to this bug, it might also be wise to use a 
> HashSet instead of the int counter _numInternalProcessing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-194) replace synchronized blocks in PoolUtils with Read/Write locks

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-194.


> replace synchronized blocks in PoolUtils with Read/Write locks
> --
>
> Key: POOL-194
> URL: https://issues.apache.org/jira/browse/POOL-194
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 2.0
>
>
> all synchronized Pools implementation in PoolUtils are designed to be fully 
> synchronized, they can be improved by replacing using synchronized blocks 
> with a Read/Write lock policy. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-193) It is safer to make org.apache.commons.pool2.impl.GenericObjectPool.evictor volatile

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-193.


> It is safer to make org.apache.commons.pool2.impl.GenericObjectPool.evictor 
> volatile
> 
>
> Key: POOL-193
> URL: https://issues.apache.org/jira/browse/POOL-193
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: Nightly Builds
> Environment: Platform: All
>Reporter: Samira Tasharofi
>  Labels: concurrency
> Fix For: 2.0
>
>
> A field of 
> [org.apache.commons.pool2.impl.GenericObjectPool|http://svn.apache.org/repos/asf/!svn/bc/1206499/commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java]
>  might need to be synchronized. Field 
> {{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} is read and 
> written in method 
> {{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}}, which 
> might be called by multiple threads concurrently. Is there a possibility that 
> {{org.apache.commons.pool2.impl.GenericObjectPool.startEvictor(long)}} gets 
> invoked concurrently? Would it be safer to make 
> {{org.apache.commons.pool2.impl.GenericObjectPool.evictor}} {{volatile}}?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-196) PooledObject.getActiveTimeMillis() does not synch. access to lastReturnTime and lastBorrowTime

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-196.


> PooledObject.getActiveTimeMillis() does not synch. access to lastReturnTime 
> and lastBorrowTime
> --
>
> Key: POOL-196
> URL: https://issues.apache.org/jira/browse/POOL-196
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> The method PooledObject.getActiveTimeMillis() compares lastReturnTime and 
> lastBorrowTime, but is not synchronised; nor are the variables volatile.
> There are two possible thread issues here: safe publication of the variables, 
> and possible window error when comparing the values.
> The method needs to be synch. and the fields need to be volatile (or the 
> getters need to be synch.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-198) LinkedBlockingDeque has some non-private fields, and a package-protected internal method

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-198.


> LinkedBlockingDeque has some non-private fields, and a package-protected 
> internal method
> 
>
> Key: POOL-198
> URL: https://issues.apache.org/jira/browse/POOL-198
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> LinkedBlockingDeque has non-private mutable fields first, last and lock - 
> these should be private.
> Also the method void unlink(Node x) is package-protected; it should be 
> private unless there's a very good reason to allow it to be 
> accessed/overridden externally - in which case it the locking conditions need 
> to be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-197) PooledObject: risky init of lastBorrowTime & lastReturnTime

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-197.


> PooledObject: risky init of lastBorrowTime & lastReturnTime
> ---
>
> Key: POOL-197
> URL: https://issues.apache.org/jira/browse/POOL-197
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> PooledObject inits lastBorrowTime & lastReturnTime (and createTime) using 
> System.currentTimeMillis().
> As well as being wasteful to call the System method 3 times, it's possible 
> that the clock will change between invocations.
> This could result in getActiveTimeMillis() returning non-zero active time 
> even though the object has never been used.
> Should probably init lastBorrowTime & lastReturnTime from createTime.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-195) Generic[Keyed]ObjectPool.startEvictor() is overrideable yet is called from the ctor

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-195.


> Generic[Keyed]ObjectPool.startEvictor() is overrideable yet is called from 
> the ctor
> ---
>
> Key: POOL-195
> URL: https://issues.apache.org/jira/browse/POOL-195
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> The method Generic[Keyed]ObjectPool.startEvictor() is overrideable yet is 
> called from the ctor - this can cause problems with subclasses, as the class 
> may be only partially constructed when the method is invoked.
> Either the method should be final, or private, or the code could be extracted 
> into a private method called by the ctor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-199) GOP/GKOP evict() method is not synchronised and is not thread-safe

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-199.


> GOP/GKOP evict() method is not synchronised and is not thread-safe
> --
>
> Key: POOL-199
> URL: https://issues.apache.org/jira/browse/POOL-199
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebb
> Fix For: 2.0
>
>
> The evict() method in Pool2 GOP/GKOP classes is not synchronised, yet it 
> relies on accessing and updating the field evictionIterator without any 
> synchronisation.
> Adding volatile to the field would help with safe publication across threads, 
> but won't address the problem of two evictions running in parallel.
> AFAICT, two threads running evict() in parallel could operate on the same 
> objects, which will almost certainly cause problems.
> The evict() method should probably be synchronised, which would also solve 
> the safe publication problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (VALIDATOR-349) TLD table should be pre-sorted

[Sebb (JIRA)]

Sebb created VALIDATOR-349:
--

 Summary: TLD table should be pre-sorted
 Key: VALIDATOR-349
 URL: https://issues.apache.org/jira/browse/VALIDATOR-349
 Project: Commons Validator
  Issue Type: Improvement
Reporter: Sebb


The TLD table is currently sorted at run-time when the class is loaded.

It would be better to sort the entries in the source table, and have a unit 
test to check that they are sorted. The unit test could output the entries in 
the correct format if it finds they are not sorted, ready to copy and paste 
into the source.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-205) GKOP - inconsistent synchronisation of poolKeyList

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-205.


> GKOP - inconsistent synchronisation of poolKeyList
> --
>
> Key: POOL-205
> URL: https://issues.apache.org/jira/browse/POOL-205
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebb
> Fix For: 2.0
>
>
> poolKeyList is an ArrayList - which is not thread-safe.
> Updates are performed whilst holding the keyLock.writeLock.
> However, the list is read in evict() without using the same lock, so there's 
> a potential for evict() to see stale or inconsistent state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-207) GenericKeyedObjectPool.clear() has unnecessary null check of objectDequeue

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-207.


> GenericKeyedObjectPool.clear() has unnecessary null check of objectDequeue
> --
>
> Key: POOL-207
> URL: https://issues.apache.org/jira/browse/POOL-207
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> GenericKeyedObjectPool.clear() registers the key, and then checks if the 
> objectDeque obtained by using the key is null.
> Since register creates the key entry in poolMap, the retrieved value should 
> never be null.
> If it is nullm then AFAICT that is a code bug, which should be reported 
> rather than ignored.
> [If it were possible for the key to be null, then the same null check should 
> be added to the private destroy method.]
> Also, register returns the ObjectDeque, so the clear() code could be 
> simplified; rather than
> {code}
> register(key);
> try {
> ObjectDeque objectDeque = poolMap.get(key);
> if (objectDeque == null) {
> return;
> }
> ...
> {code}
> the method could use:
> {code}
> ObjectDeque objectDeque = register(key);
> try {
> ...
> {code}
> Similarly for the private destroy method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-201) Classes Generic[Keyed]ObjectPoolConfig are generic - but why?

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-201.


> Classes Generic[Keyed]ObjectPoolConfig are generic - but why?
> -
>
> Key: POOL-201
> URL: https://issues.apache.org/jira/browse/POOL-201
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> The classes Generic[KeyedObject]PoolConfig are generic - but why?
> They don't use the parameterised types anywhere as far as I can tell.
> Unless I'm missing something, I don't think the parameterisation provides any 
> useful compile-time checking; it just make the ctors harder to read ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-202) GenericKeyedObjectPool.close() can interfere with evict(); eviction[Key]Iterator is not consistently synched.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-202.


> GenericKeyedObjectPool.close() can interfere with evict(); 
> eviction[Key]Iterator is not consistently synched.
> -
>
> Key: POOL-202
> URL: https://issues.apache.org/jira/browse/POOL-202
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebb
> Fix For: 2.0
>
>
> As far as I can tell, calling close during an evict() run can cause problems, 
> because close() sets the eviction[Key]Iterator fields to null.
> I suspect close() and evict() should be mutually exclusive.
> Maybe close does not need to nullify the eviction[Key]Iterator fields, but 
> there's probably other mutually incompatible behaviour.
> Or maybe the fields should be nulled in startEvictor.
> Also, the fields eviction[Key]Iterator aren't volatile and aren't always 
> accessed under the same lock so might not be safely published.
> That would be solved by moving the nulling to startEvictor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-206) GOP/GKOP close() - incorrect behaviour with evict() ?

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-206.


> GOP/GKOP close() - incorrect behaviour with evict() ?
> -
>
> Key: POOL-206
> URL: https://issues.apache.org/jira/browse/POOL-206
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> GOP/GKOP close() methods close the pool before stopping the evictor; that 
> seems wrong.
> The evict() method calls assertOpen() so the evictor thread should be stopped 
> before closing the pool.
> Also, the evictor thread should probably be allowed to complete if currently 
> active.
> Not sure about calling clear() before the evictor is cancelled; should 
> perhaps be run afterwards?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-177) GenericKeyedObjectPoolFactory and GenericObjectPoolFactory to share a common superclass

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-177.


> GenericKeyedObjectPoolFactory and GenericObjectPoolFactory to share a common 
> superclass
> ---
>
> Key: POOL-177
> URL: https://issues.apache.org/jira/browse/POOL-177
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Gary Gregory
> Attachments: POOL-177.diff, POOL-177.diff
>
>
> I see now in trunk that GenericKeyedObjectPoolConfig extends 
> GenericObjectPoolConfig, which I like.
> It seems that the next step would be for GenericKeyedObjectPoolFactory and 
> GenericObjectPoolFactory to share a common superclass.
> To see what I mean, look at the patch in this ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-209) SharedPoolDataSource does not handle null keys correctly

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-209.


> SharedPoolDataSource does not handle null keys correctly
> 
>
> Key: POOL-209
> URL: https://issues.apache.org/jira/browse/POOL-209
> Project: Commons Pool
>  Issue Type: Bug
> Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, 
> jTDS 1.2.5)
>Reporter: Gabor Horvath
> Attachments: GenericKeyedObjectPool.java
>
>
> GenericKeyedObjectPool.borrowObject does not invalidate object if 
> validateObject fails (line ~1200). I guess invalidation would be needed for 
> objects which are not newly created (newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed 
> on jTDS level but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes 
> "java.sql.SQLException: Invalid state, the Connection object is closed"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-164) GenericKeyedObjectPoolFactory should be able to load itself from a properties file

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-164.


> GenericKeyedObjectPoolFactory should be able to load itself from a properties 
> file
> --
>
> Key: POOL-164
> URL: https://issues.apache.org/jira/browse/POOL-164
> Project: Commons Pool
>  Issue Type: New Feature
>Reporter: Mircea Markus
>
> This would be quite handy. Generally pooling configs are not hardcoded, but 
> specified in a config and then passed to the 
> GenericKeyedObjectPoolFactory/GenericObjectPoolFactory. It would be handy to 
> allow a user to load all these configuration from a property file.
> a new constructor would be needed: GenericKeyedObjectPoolFactory(property)
> or even better GenericKeyedObjectPoolFactory(URL)
> Glad to contribute this myself if you find it useful. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-211) Proxy support for pooled objects

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-211.


> Proxy support for pooled objects
> 
>
> Key: POOL-211
> URL: https://issues.apache.org/jira/browse/POOL-211
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.6, 2.0
>Reporter: Brad Koehn
>  Labels: features, patch
> Fix For: 2.0
>
> Attachments: src.jar, test.jar
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Attached are files and tests that would allow users of commons-pool to 
> interact with a proxy to the pooled object rather than the pooled object 
> itself. This provides two benefits: detection of leaked pooled objects (when 
> returnObject() isn't called) with a stack trace and detection of using pooled 
> objects after they have been returned to the pool. The system provides a 
> delegate which can be placed in front of any ObjectPool, similar to calling 
> Collections.unmodifiableCollection(). Callers do not know that they're 
> working with a proxy rather than the pooled object itself. Implementations 
> are provided to use Java proxies or CGLib (useful when the pooled object 
> doesn't implement an interface). Unit tests are also provided. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-175) Add Builders for Configuration classes

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-175.


> Add Builders for Configuration classes
> --
>
> Key: POOL-175
> URL: https://issues.apache.org/jira/browse/POOL-175
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 2.0
>
>
> As suggested by Steven in the mailing-list thread:
> "Last suggestion/question is about making inner (public static final) Builder 
> pattern classes within the concrete Config classes (and possibly defining an 
> abstract  create() method in the Abstract class).
> This would further simplify the programmatic creation of the Config classes."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-174) Configuration classes must be thread-safe

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-174.


> Configuration classes must be thread-safe
> -
>
> Key: POOL-174
> URL: https://issues.apache.org/jira/browse/POOL-174
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>
> New Configuration classes added with POOL-173 have to be made thread-safety



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (VALIDATOR-341) Make TLD list configurable

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/VALIDATOR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262279#comment-14262279
 ] 

Sebb commented on VALIDATOR-341:


It seems a bit wasteful to have to parse the list each time when this can be 
done once just prior to creating a release.
[Indeed the sort could be done beforehand as well, and the unit test could 
check it]

Also I'm thinking that the user should only have to provide a list of 
additional TLDs.
I don't think they are ever deleted.

The file search would need to be optional, I think, perhaps as a new static 
method.
It would otherwise be unnecessary overhead for everyone, even those who don't 
need/want it.

Might also be worth looking at whether it's worth serialising/de-serialising 
the data rather than recreating it on startup.
For example, if an external file is found, update the table and serialise to 
disk.
If a serialised file is found, use that, else the external file.
Could compare dates to decide which to use; there's always the option of 
deleting the serialised file.
But maybe that is taking things too far.

> Make TLD list configurable
> --
>
> Key: VALIDATOR-341
> URL: https://issues.apache.org/jira/browse/VALIDATOR-341
> Project: Commons Validator
>  Issue Type: New Feature
>  Components: Framework
>Reporter: Benedikt Ritter
>  Labels: TLD, domains, email
>
> Since the list of valid TLDs changes from time to time, it makes sense to let 
> users configure the list of valid TLDs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-176) GenericKeyedObjectPool should support softMinEvictableIdleTimeMillis a la GenericObjectPool

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-176.


> GenericKeyedObjectPool should support softMinEvictableIdleTimeMillis a la 
> GenericObjectPool 
> 
>
> Key: POOL-176
> URL: https://issues.apache.org/jira/browse/POOL-176
> Project: Commons Pool
>  Issue Type: New Feature
>Affects Versions: 1.5.4
>Reporter: Gary Gregory
> Fix For: 2.0
>
>
> GenericKeyedObjectPool should support softMinEvictableIdleTimeMillis a la 
> GenericObjectPool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-172) Add JMX (MBean) management and monitoring

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-172.


> Add JMX (MBean) management and monitoring
> -
>
> Key: POOL-172
> URL: https://issues.apache.org/jira/browse/POOL-172
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 1.5.4, 2.0, 3.0
>Reporter: Steve Siebert
>Assignee: Mark Thomas
> Fix For: 2.0
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> All JMX MBeans for pool monitoring and runtime management (configuration).  
> In addition to adding runtime configuration and support for JMX, this feature 
> could possibly satisfy #POOL-159 and #POOL-98.
> Need to look at Tomcat jdbc-pool implementation to see what we can learn, and 
> if we can contribute back to that project as well.  Need to analyze related 
> tickets, commons mailing list, and develop an API for the MBean(s).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-178) Common interfaces and abstract classes for BOP and BKOP

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-178.


> Common interfaces and abstract classes for BOP and BKOP
> ---
>
> Key: POOL-178
> URL: https://issues.apache.org/jira/browse/POOL-178
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Gary Gregory
> Fix For: 2.0
>
> Attachments: POOL-178.diff
>
>
> I have created a patch that IMO should make it easier for us to further 
> refactor code.
> In brief, OP/BOP and KOP/BKOP do not have a common parent interface/class. 
> This patch remedies this by pulling up the 
> close/clear/getNumActive/getNumIdle methods into a new interface and class.
> This seems not very controversial (to me at least), so I would like to commit 
> it (unless riots spread from Paris to this list.)
> Thoughts?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-220) PooledObject#compareTo() is not guaranteed consistent with equals

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-220.


> PooledObject#compareTo() is not guaranteed consistent with equals
> -
>
> Key: POOL-220
> URL: https://issues.apache.org/jira/browse/POOL-220
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> PooledObject#compareTo only returns 0 if the getLastRuntime values are equal 
> AND the identityHashCodes are equal.
> This will work OK for the identity comparison, but is not guaranteed to work 
> in all other cases.
> It's possible for two distinct objects to have the same identityHashCode. 
> If such objects happen to have the same lastRuntime, then compareTo will 
> return 0, but equals (which defaults to Object#equals) will return false.
> It's not very likely, but it is possible.
> A simple fix would be to define equals() to return true only in the case that 
> the lastRuntime values and identityHashCodes are equal.
> Also, the Javadoc for the compareTo method ought to make clear what the 
> ordering is intended to achieve.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-215) GenericKeyedObjectPool - multiple mutable fields not published safely

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-215.


> GenericKeyedObjectPool - multiple mutable fields not published safely
> -
>
> Key: POOL-215
> URL: https://issues.apache.org/jira/browse/POOL-215
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> The GenericKeyedObjectPool has multiple mutable instance fields that are 
> neither volatile nor protected by syncronisation.
> This means that updates by one thread may not be seen by other threads.
> The following fields should either be made volatile, or be protected by a 
> lock.
> The lock is more suitable if the main usage is already protected by a lock.
> blockWhenExhausted
> evictionPolicy (getter and setter should use evictionLock)
> lifo
> maxIdlePerKey
> maxTotal
> maxTotalPerKey
> maxWait
> minEvictableIdleTimeMillis (getter and setter should use evictionLock)
> numTestsPerEvictionRun (getter and setter should use evictionLock)
> testWhileIdle (getter and setter should use evictionLock)
> timeBetweenEvictionRunsMillis (getter and setter should use evictionLock)
> Note that where the same fields appear in GOP, they are protected (apart from 
> evictionPolicy, see POOL-214)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-217) PoolUtils.MIN_IDLE_TIMER could be provided using an IODH

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-217.


> PoolUtils.MIN_IDLE_TIMER could be provided using an IODH
> 
>
> Key: POOL-217
> URL: https://issues.apache.org/jira/browse/POOL-217
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Sebb
> Fix For: 2.0
>
> Attachments: POOL-217.patch
>
>
> PoolUtils.MIN_IDLE_TIMER could be provided using an IODH.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-214) GenericObjectPool.evictionPolicy not thread-safe

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-214.


> GenericObjectPool.evictionPolicy not thread-safe
> 
>
> Key: POOL-214
> URL: https://issues.apache.org/jira/browse/POOL-214
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> The instance field GenericObjectPool.evictionPolicy is not updated in a 
> thread-safe way.
> It either needs to be made volatile, or the getters/setters could synch. on 
> the evictionLock.
> The latter is probably more sensible, as the field is used whilst holding 
> that lock.
> [Note: AFAICT, that is currently the only unsafe field in GOP]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-221) PooledObject.state does not need to be volatile

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-221.


> PooledObject.state does not need to be volatile
> ---
>
> Key: POOL-221
> URL: https://issues.apache.org/jira/browse/POOL-221
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.0
>
>
> The field PooledObject.state is volatile, but is also always accessed in a 
> synchronised method except in toString().
> The volatile modifier is not cost free; it might be better to remove it and 
> add a small synch. block in toString().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-219) Example documentation refers to StackObjectPool which is not present in Pool2

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-219.


> Example documentation refers to StackObjectPool which is not present in Pool2
> -
>
> Key: POOL-219
> URL: https://issues.apache.org/jira/browse/POOL-219
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebb
> Fix For: 2.0
>
>
> The example documentation refers to StackObjectPool which is not present in 
> Pool2.
> Either the example needs to be updated, or the StackObjectPool class needs to 
> be implemented (e.g. copied from 1.x).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-230) waiting on <0x00000000e7440168> (a org.apache.commons.pool.impl.GenericObjectPool$Latch)

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-230.


> waiting on <0xe7440168> (a 
> org.apache.commons.pool.impl.GenericObjectPool$Latch)
> 
>
> Key: POOL-230
> URL: https://issues.apache.org/jira/browse/POOL-230
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.4
> Environment: tomcat using dbcp
>Reporter: jerrybi
>
> "Thread-20" daemon prio=10 tid=0x7f5810214000 nid=0x5f7b in Object.wait() 
> [0x7f581527c000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
>   at java.lang.Object.wait(Native Method)
>   - waiting on <0xe7440168> (a 
> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>   at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1112)
>   - locked <0xe7440168> (a 
> org.apache.commons.pool.impl.GenericObjectPool$Latch)
>   at 
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
>   at 
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> it seems that the problem bellow still exits. 
> https://issues.apache.org/jira/browse/POOL-149
> I am using commons-dbcp-1.3 and commons-pool-1.5.4



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-231) GOP, GKOP invalidateObject is not threadsafe

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-231.


> GOP, GKOP invalidateObject is not threadsafe
> 
>
> Key: POOL-231
> URL: https://issues.apache.org/jira/browse/POOL-231
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: Nightly Builds
>Reporter: Phil Steitz
> Fix For: 2.0
>
>
> There does not appear to be sufficient sync protection for the destroyCount 
> and createCount counters when destroy is activated by invalidateObject in 
> GOP, GKOP, v2 trunk.  The test below fails when added to GOP tests. The 
> destroyCount is over-incremented due (I think) to the fact that multiple 
> threads can enter destroy before the object being invalidated is removed from 
> allObjects.  This problem was originally reported by Thomas Neidhart in a 
> comment on POOL-213.
> {code}
> @Test
> public void testConcurrentInvalidate() throws Exception {
> // Get allObjects and idleObjects loaded with some instances
> final int nObjects = 1000;
> pool.setMaxTotal(nObjects);
> pool.setMaxIdle(nObjects);
> final Object[] obj = new Object[nObjects];
> for (int i = 0; i < nObjects; i++) {
> obj[i] = pool.borrowObject();
> }
> for (int i = 0; i < nObjects; i++) {
> if (i % 2 == 0) {
> pool.returnObject(obj[i]);
> }
> }
> final int nThreads = 100;
> final int nIterations = 100;
> final InvalidateThread[] threads = new InvalidateThread[nThreads];
> // Randomly generated list of distinct invalidation targets
> final ArrayList targets = new ArrayList();
> final Random random = new Random();
> for (int j = 0; j < nIterations; j++) {
> // Get a new invalidation target
> Integer targ = new Integer(random.nextInt(nObjects));
> while (targets.contains(targ)) {
> targ = new Integer(random.nextInt(nObjects));
> }
> targets.add(targ);
> // Launch nThreads threads all trying to invalidate the target
> for (int i = 0; i < nThreads; i++) {
> threads[i] = new InvalidateThread(pool, obj[targ]);
> }
> for (int i = 0; i < nThreads; i++) {
> new Thread(threads[i]).start();
> }
> boolean done = false;
> while (!done) {
> done = true;
> for (int i = 0; i < nThreads; i++) {
> done = done && threads[i].complete();
> }
> Thread.sleep(100);
> }
> }
> Assert.assertEquals(nIterations, pool.getDestroyedCount());
> }
> 
> static class InvalidateThread implements Runnable {
> final private Object obj;
> final private ObjectPool pool;
> private boolean done = false;
> public InvalidateThread(ObjectPool pool, Object obj) {
> this.obj = obj;
> this.pool = pool;
> }
> public void run() {
> try {
> pool.invalidateObject(obj);
> } catch (IllegalStateException ex) {
> // Ignore
> } catch (Exception ex) {
> Assert.fail("Unexpected exception " + ex.toString());
> } finally {
> done = true;
> }
> }
> public boolean complete() {
> return done;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-229) Move AbandonedObjectPool from DBCP to POOL

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-229.


> Move AbandonedObjectPool from DBCP to POOL
> --
>
> Key: POOL-229
> URL: https://issues.apache.org/jira/browse/POOL-229
> Project: Commons Pool
>  Issue Type: New Feature
>Reporter: Phil Steitz
> Fix For: 2.0
>
> Attachments: dbcp.patch
>
>
> The AbandonedObjectPool functionality in DBCP should be incorporated in 
> Commons Pool.  In 2.0, GenericObjectPool maintains references to checkout out 
> objects, so this capability can be provided directly by this class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-276) Validation code invoked on unexpected timing.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-276.


> Validation code invoked on unexpected timing.
> -
>
> Key: POOL-276
> URL: https://issues.apache.org/jira/browse/POOL-276
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: jdk1.7.0_55 on CentOS6
>Reporter: Noriyuki Torii
> Fix For: 2.3
>
>
> I found BasePooledObjectFactory.validateObject() of commons-pool sometimes 
> called on unexpected timing.
> I've configured the pool so as to the validateObject() would be invoked only 
> on instance creation, but sometimes it was invoked for "non-fresh" instance 
> on borrowing.
> Reproduction code below.
> {code}
> import java.io.*;
> import java.util.*;
> import org.apache.commons.pool2.*;
> import org.apache.commons.pool2.impl.*;
> public class reproduction
> {
> private static class MyPooledObj
> {
> volatile int i = 0;
> final String uuid = UUID.randomUUID().toString();
> }
> private static class MyFactory extends 
> BasePooledObjectFactory
> {
> @Override
> public MyPooledObj create() {
> return new MyPooledObj();
> }
> @Override
> public PooledObject wrap(MyPooledObj o) {
> return new DefaultPooledObject(o);
> }
> @Override
> public boolean validateObject(PooledObject o) {
> MyPooledObj myobj = o.getObject();
> synchronized (myobj) {
> myobj.i++;
> }
> System.out.println("Validated.");
> return true;
> }
> }
> public static void main(String[] args)
> throws Exception
> {
> GenericObjectPoolConfig poolCfg = new GenericObjectPoolConfig() ;
> poolCfg.setMaxTotal(1);
> poolCfg.setMaxIdle(1);
> poolCfg.setBlockWhenExhausted(true);
> poolCfg.setMaxWaitMillis(1);
> poolCfg.setTestOnCreate(true); // should be validated only on creation
> poolCfg.setTestOnBorrow(false);
> poolCfg.setTestOnReturn(false);
> poolCfg.setTestWhileIdle(false);
> final GenericObjectPool pool =
> new GenericObjectPool(new MyFactory(), poolCfg);
> final MyPooledObj o = pool.borrowObject();
> System.out.printf("%d: %s\n", o.i, o.uuid);
> Timer t = new Timer();
> t.schedule
> (new TimerTask() {
> public void run() {
> pool.returnObject(o);
> }
> }, 3000);
> // validation will occur again for non-fresh instance,
> // confirmed on commons-pool2-2.2 with jdk1.7.0_55
> MyPooledObj o2 = pool.borrowObject();
> System.out.printf("%d: %s\n", o2.i, o2.uuid);
> pool.returnObject(o2);
> pool.close();
> t.cancel();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-281) Infinite loop

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-281.


> Infinite loop
> -
>
> Key: POOL-281
> URL: https://issues.apache.org/jira/browse/POOL-281
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: Linux,JDK1.6.23,Tomcat6
>Reporter: lqm
> Fix For: 2.3
>
>
> I use the pool2 as a tcp connection pool,when I start tomcat,one thread occur 
> an infinite loop In the advance() method,but it sometimes happens, not 
> always,the java statck information is as follows:
> Thread 2194: (state = IN_JAVA)
>  - org.apache.commons.pool2.impl.LinkedBlockingDeque$AbstractItr.advance() 
> @bci=42, line=1163 (Compiled frame; information may be imprecise)
>  - org.apache.commons.pool2.impl.LinkedBlockingDeque$AbstractItr.next() 
> @bci=29, line=1184 (Interpreted frame)
>  - org.apache.commons.pool2.impl.GenericKeyedObjectPool.clearOldest() 
> @bci=85, line=741 (Interpreted frame)
>  - 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.create(java.lang.Object) 
> @bci=56, line=991 (Interpreted frame)
>  - 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(java.lang.Object,
>  long) @bci=59, line=356 (Interpreted frame)
>  - 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(java.lang.Object)
>  @bci=6, line=277 (Interpreted frame)
> Thread 2195: (state = BLOCKED)
>  - sun.misc.Unsafe.park(boolean, long) @bci=0 (Interpreted frame)
>  - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, 
> line=158 (Interpreted frame)
>  - 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt() 
> @bci=1, line=811 (Interpreted frame)
>  - 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
>  int) @bci=48, line=842 (Interpreted frame)
>  - 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long)
>  @bci=112, line=2033 (Interpreted frame)
>  - org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(long, 
> java.util.concurrent.TimeUnit) @bci=50, line=569 (Interpreted frame)
>  - 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(java.lang.Object,
>  long) @bci=105, line=363 (Interpreted frame)
>  - 
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(java.lang.Object)
>  @bci=6, line=277 (Interpreted frame)
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (POOL-236) Replace JMX notifications with an event listener

[Phil Steitz (JIRA)]

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

Phil Steitz updated POOL-236:
-
Fix Version/s: 2.2

> Replace JMX notifications with an event listener
> 
>
> Key: POOL-236
> URL: https://issues.apache.org/jira/browse/POOL-236
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Mark Thomas
> Fix For: 2.2
>
>
> JMX notifications were chosen as a way to expose swallowed exceptions to the 
> user without adding a dependency on a logging framework. In discussions about 
> logging for DBCP, James Carman suggested an event listener which is a much 
> better solution to POOL's logging problem than JMX notifications.
> Aim to implement this change in time for the 2.0 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-270) timeBetweenEvictionRunsMillis from config is ignored

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-270.


> timeBetweenEvictionRunsMillis from config is ignored
> 
>
> Key: POOL-270
> URL: https://issues.apache.org/jira/browse/POOL-270
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Berman
> Fix For: 2.3
>
>
> In the constructor for GenericKeyedObjectPool, the setting for 
> timeBetweenEvictionRunsMillis is always overridden by 
> minEvictableIdleTimeMillis.
> First setConfig() is called, which, ends up starting an evictor with a period 
> of timeBetweenEvictionRunsMillis, as expected. but the final line of the 
> constructor calls startEvictor() again with minEvictableIdleTimeMillis, which 
> kills the first timer and starts a new one with the new period. This means 
> effectively the timeBetweenEvictionRunsMillis from the config is not used for 
> anything.
> I want testWhileIdle's verifications to run more often than I want the 
> timeout for evicting idle objects, which does not appear to be possible given 
> this bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-236) Replace JMX notifications with an event listener

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-236.


> Replace JMX notifications with an event listener
> 
>
> Key: POOL-236
> URL: https://issues.apache.org/jira/browse/POOL-236
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Mark Thomas
> Fix For: 2.2
>
>
> JMX notifications were chosen as a way to expose swallowed exceptions to the 
> user without adding a dependency on a logging framework. In discussions about 
> logging for DBCP, James Carman suggested an event listener which is a much 
> better solution to POOL's logging problem than JMX notifications.
> Aim to implement this change in time for the 2.0 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-277) Monitor contention at BaseGenericObjectPool

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-277.


> Monitor contention at BaseGenericObjectPool
> ---
>
> Key: POOL-277
> URL: https://issues.apache.org/jira/browse/POOL-277
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Lucas Pouzac
>Assignee: Bernd Eckenfels
>  Labels: concurrency, performance
> Fix For: 2.3
>
> Attachments: monitor_contention_basegenericobjectpool.png, 
> monitor_contention_basegenericobjectpool_after_pull_request.png, 
> nolockstats2.patch
>
>
> Updating JMX causes synchronization while the service is secondary. See 
> screenshot.
> I create a Pull Request [#1|https://github.com/apache/commons-pool/pull/1].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-240) GKOP: invalidateObject does not unblock threads waiting in borrowObject

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-240.


> GKOP: invalidateObject does not unblock threads waiting in borrowObject
> ---
>
> Key: POOL-240
> URL: https://issues.apache.org/jira/browse/POOL-240
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Dan McNulty
> Fix For: 2.1
>
> Attachments: InvalidateObjectTest.java
>
>
> It appears that when threads are blocked in GKOP.borrowObject due to max 
> object limits being reached and another thread calls invalidateObject, the 
> threads blocked in GKOP.borrowObject are not woken up to attempt to create a 
> new object.
> Have the semantics changed for invalidate in 2.0?
> Attached is a unit test that demonstrates this issue. I should note that this 
> test passed against POOL 1.5, after making the appropriate changes due to the 
> API changes in 2.0.
> After a cursory glance through the source for GenericObjectPool, it looks 
> like it might be affected by the same issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-237) returnObject call is stuck for more than 11 mins

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-237.


> returnObject call is stuck for more than 11 mins
> 
>
> Key: POOL-237
> URL: https://issues.apache.org/jira/browse/POOL-237
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.6
> Environment: Its our Production environment
>Reporter: samjna
> Attachments: commons-pool-1.6.jar
>
>
> Hi,
> I recently upgraded from Commons-pool.1.3 API to 1.6, I use this 
> GenericObjectPool for Corba connection pooling. But today I noticed that my 
> server thread was stuck because of returnObject. I thought it was resolved 
> already, but doesnt look like.
> <8-Aug-2013 9:14:09 o'clock PM UTC>   
>   <[ACTIVE] ExecuteThread:
>  '177' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> 
> <> <1375996449633>  <[STUCK] ExecuteThread:
>  '73' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for 
> "629" seconds working on the request "com.x.services.
> x.service.impl.XxxEJB_mwazfy_EOImpl", which is more than the 
> configured time (StuckThreadMaxTime) of "600" seconds
> . Stack trace:
> 
> org.apache.commons.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:916)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-263) GenericObjectPool close and returnObject is not synchronized

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-263.


> 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
> Fix For: 2.3
>
>
> 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.3.4#6332)

[jira] [Closed] (POOL-250) wish to Commons Pool 2 works with Android environment

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-250.


> wish to Commons Pool 2 works with Android environment
> -
>
> Key: POOL-250
> URL: https://issues.apache.org/jira/browse/POOL-250
> Project: Commons Pool
>  Issue Type: Wish
>Affects Versions: 2.1
> Environment: Android
>Reporter: Jungtaek Lim
>
> This issue starts at https://github.com/xetorthio/jedis/issues/538.
> Jedis - Java Redis Client - seems to stop working with Android at that time 
> Jedis changes Common Pool version from 1.6 to 2.0.
> I found Commons Pool 2 uses jmx, which Android cannot support.
> I believe it makes error with class loading, so disabling jmx cannot resolve 
> this issue.
> {code}
> public BaseGenericObjectPool(BaseObjectPoolConfig config,
> String jmxNameBase, String jmxNamePrefix) {
> if (config.getJmxEnabled()) {
> this.oname = jmxRegister(jmxNameBase, jmxNamePrefix);
> } else {
> this.oname = null;
> }
> ...
> {code}
> {code}
> private ObjectName jmxRegister(String jmxNameBase, String jmxNamePrefix) {
> ObjectName objectName = null;
> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
> int i = 1;
> ...
> {code}
> Please double check Commons Pool 2 is not working with Android.
> And if it's not working, I wish you to make Commons Pool 2 jmx usage 
> selectable.
> ps. error message follows
> {code}
> W  VFY: unable to find class referenced in signature 
> (Ljavax/management/ObjectName;)
> I  Could not find method 
> java.lang.management.ManagementFactory.getPlatformMBeanServer, referenced 
> from method org.apache.commons.pool2.impl.BaseGenericObjectPool.jmxRegister
> W  VFY: unable to resolve static method 22260: 
> Ljava/lang/management/ManagementFactory;.getPlatformMBeanServer 
> ()Ljavax/management/MBeanServer;
> D  VFY: replacing opcode 0x71 at 0x0001
> W  VFY: unable to find class referenced in signature 
> (Ljavax/management/ObjectName;)
> I  Could not find method 
> java.lang.management.ManagementFactory.getPlatformMBeanServer, referenced 
> from method org.apache.commons.pool2.impl.BaseGenericObjectPool.jmxUnregister
> W  VFY: unable to resolve static method 22260: 
> Ljava/lang/management/ManagementFactory;.getPlatformMBeanServer 
> ()Ljavax/management/MBeanServer;
> D  VFY: replacing opcode 0x71 at 0x0004
> D  GC_FOR_ALLOC freed 396K, 5% free 9382K/9808K, paused 29ms, total 29ms
> W  VFY: unable to resolve exception class 3559 
> (Ljavax/management/MBeanRegistrationException;)
> W  VFY: unable to find exception handler at addr 0xe
> W  VFY:  rejected 
> Lorg/apache/commons/pool2/impl/BaseGenericObjectPool;.jmxUnregister ()V
> W  VFY:  rejecting opcode 0x0d at 0x000e
> W  VFY:  rejected 
> Lorg/apache/commons/pool2/impl/BaseGenericObjectPool;.jmxUnregister ()V
> W  Verifier rejected class 
> Lorg/apache/commons/pool2/impl/BaseGenericObjectPool;
> DJDWP invocation returning with exceptObj=0x41f58880 
> (Ljava/lang/ClassNotFoundException;)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-248) GenericObjectPool.returnObject() is NOT throwing IllegalStateException for object has already been returned

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-248.


> GenericObjectPool.returnObject() is NOT throwing IllegalStateException for 
> object has already been returned
> ---
>
> Key: POOL-248
> URL: https://issues.apache.org/jira/browse/POOL-248
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Warren Chen
> Fix For: 2.2
>
>
> When GenericObjectPool is created using AbandonedConfig, the pool is NOT 
> throwing "IllegalStateException: Object has already been returned to this 
> pool or is invalid" for object has already been returned.
> final GenericObjectPool pool = new GenericObjectPool(
>   new SimpleFactory(), new 
> GenericObjectPoolConfig(),
>   new AbandonedConfig());
>   String obj1 = pool.borrowObject();
>   System.out.println("after borrowing obj1");
>   System.out.println("numActive=" + pool.getNumActive());
>   System.out.println("numIdle=" + pool.getNumIdle());
>   System.out.println("return obj1");
>   pool.returnObject(obj1);
>   System.out.println("numActive=" + pool.getNumActive());
>   System.out.println("numIdle=" + pool.getNumIdle());
>   
>   System.out.println("return obj1 again");
>   pool.returnObject(obj1);
>   System.out.println("numActive=" + pool.getNumActive());
>   System.out.println("numIdle=" + pool.getNumIdle());
> Output:
> after borrowing obj1
> numActive=1
> numIdle=0
> return obj1
> numActive=0
> numIdle=1
> return obj1 again
> numActive=-1
> numIdle=2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-259) Client wait time is not updated when max wait is configured to be unlimited

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-259.


> 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.3.4#6332)

[jira] [Closed] (POOL-261) Make net.sf.cglib.proxy package import optional

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-261.


> Make net.sf.cglib.proxy package import optional
> ---
>
> Key: POOL-261
> URL: https://issues.apache.org/jira/browse/POOL-261
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.2
> Environment: OSGi
>Reporter: Balazs Zsoldos
> Fix For: 2.3
>
>
> To use commons-pool2 inside an OSGi environment, we must drop cglib into the 
> container as well although we do not need it.
> E.g.: commons-dbcp2 uses commons-pool in the way that cglib is never called.
> Please add resolution:=optional to the Import-Package section.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-265) Evictor automatically destroys object after some time, even when conditions are not met

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-265.


> Evictor automatically destroys object after some time, even when conditions 
> are not met
> ---
>
> Key: POOL-265
> URL: https://issues.apache.org/jira/browse/POOL-265
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Mac OS 10.8.2
>Reporter: garima
>
> We have created generic object pool using following configuration. But 
> evictor which is supposed to run in every 2.5 min and check for min idle 
> connections and destroy objects (other than min idle connections i.e 2) which 
> have been idle from last 5 mins is not working as expected. Evictor starts 
> destroying objects(min idle instances) in every 15 minutes, which is 
> absolutely wrong as per documentation and should not be happened. Can you 
> please look into this issue?
>   INX_POOL2 = new GenericObjectPool(new 
> InxCacheFactory());
>   INX_POOL2.setMinIdle(2);
>   INX_POOL2.setNumTestsPerEvictionRun(1);
>   INX_POOL2.setSoftMinEvictableIdleTimeMillis(30);
>   INX_POOL2.setTimeBetweenEvictionRunsMillis(15);
>   INX_POOL2.setMaxTotal(200);
>   INX_POOL2.setMaxWaitMillis(5000);
>   INX_POOL2.setTestOnBorrow(false);



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-275) BaseProxyHandler.pooledObject is not volatile or synch, so is not guaranteed to be safely published.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-275.


> BaseProxyHandler.pooledObject is not volatile or synch, so is not guaranteed 
> to be safely published.
> 
>
> Key: POOL-275
> URL: https://issues.apache.org/jira/browse/POOL-275
> Project: Commons Pool
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 2.3
>
>
> BaseProxyHandler.pooledObject is not volatile or synch, so is not guaranteed 
> to be safely published.
> The class Javadoc does not state whether it is intended to be thread-safe or 
> not, but I would expect the class might be called from multiple threads.
> One solution would be to make the field volatile.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-273) Update cglib to 3.1 from 3.0

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-273.


> Update cglib to 3.1 from 3.0
> 
>
> Key: POOL-273
> URL: https://issues.apache.org/jira/browse/POOL-273
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.2
> Environment: Apache Maven 3.2.3 
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
> Maven home: C:\Java\apache-maven-3.2.3
> Java version: 1.7.0_65, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_65\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.3
>
>
> Update cglib to 3.1 from 3.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-274) Update asm-util to 5.0.3 from 4.0

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-274.


> Update asm-util to 5.0.3 from 4.0
> -
>
> Key: POOL-274
> URL: https://issues.apache.org/jira/browse/POOL-274
> Project: Commons Pool
>  Issue Type: Improvement
>Affects Versions: 2.2
> Environment: Apache Maven 3.2.3 
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
> Maven home: C:\Java\apache-maven-3.2.3
> Java version: 1.7.0_65, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_65\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.3
>
>
> Update asm-util to 5.0.3 from 4.0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-187) TestGenericKeyedObjectPool.testMaxTotalLRU method falls in an infinite loops

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-187.


> TestGenericKeyedObjectPool.testMaxTotalLRU method falls in an infinite loops
> 
>
> Key: POOL-187
> URL: https://issues.apache.org/jira/browse/POOL-187
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
> Fix For: 2.0
>
>
> After having restored the Genrics, the 
> TestGenericKeyedObjectPool.testMaxTotalLRU test method is stuck and I didn't 
> figure out the reason :(
> That's why I currently put the @Ignore annotation, so JUnit can continue 
> running, but I need help to fix it.
> I suspect Continuum is stuck too, but I think I don't have enough karma to 
> unlock it.
> Many thanks in advance!!!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-188) Confusing PoolUtils.ErodingKeyedObjectPool.numIdle(K key) method; bug in ErodingKeyedObjectPool.returnObject(K key, V obj) ?

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-188.


> Confusing PoolUtils.ErodingKeyedObjectPool.numIdle(K key) method; bug in 
> ErodingKeyedObjectPool.returnObject(K key, V obj) ?
> 
>
> Key: POOL-188
> URL: https://issues.apache.org/jira/browse/POOL-188
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sebb
>Assignee: Mark Thomas
> Fix For: 2.0
>
> Attachments: POOL-188.patch
>
>
> numIdle(key) is equivalent to PoolUtils.ErodingKeyedObjectPool.getNumIdle() - 
> unless the method getKeyedPool() is overridden.
> It's confusing that the key parameter is not used - this may be the cause of 
> a bug, as the method is used internally by 
> ErodingKeyedObjectPool.returnObject(K key, V obj).
> It looks like returnObject() should probably call getNumIdle(key) rather than 
> numIdle(key).
> In which case the confusing numIdle method can be deleted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-185) when continue kill all connection , Cannot get a connection.

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-185.


> when continue kill all connection ,  Cannot get a connection.
> -
>
> Key: POOL-185
> URL: https://issues.apache.org/jira/browse/POOL-185
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 1.5.5
> Environment: suse enterprise linux 11 (64 bit)
> jdk1.5.0_21 (32 bit)
> oracle 10.2.0.3(64 bit)
> commons-pool-1.5.5.jar
> commons-dbcp-1.3.jar
> configure
>  
>   value="jdbc:oracle:thin:@10.70.193.1:1521:ora10g"/>
>  
>  
>  
>  
>  
>  
>  
>  
>
>
>
>
>
>Reporter: cauherk
>
> After program startup,continue kill all connection.Use oracle command "alter 
> system kill session 'sid,#p'".
> Exception
> org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool 
> error Timeout waiting for idle object
>   at 
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:114)
>   at 
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
>   at test.TestConn.aa(TestConn.java:18)
>   at test.TestConn.main(TestConn.java:49)
> Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
>   at 
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1144)
>   at 
> org.apache.commons.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:79)
>   at 
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
>   ... 7 more
> java.sql.SQLException: Cannot get a connection, pool error Timeout waiting 
> for idle object
>   at test.TestConn.aa(TestConn.java:18)
>   at test.TestConn.main(TestConn.java:49)
> I debug org.apache.commons.pool.impl.GenericObjectPool.
> public synchronized void evict() throws Exception {
> assertOpen();
> if(!_pool.isEmpty()) {
>   ...
> } // if !empty
> }
> 
>  but _pool.isEmpty() is always empty,can not run into.
>private synchronized int calculateDeficit(boolean incrementInternal) {
> int objectDeficit = getMinIdle() - getNumIdle();
> if (_maxActive > 0) {
> int growLimit = Math.max(0,
> getMaxActive() - getNumActive() - getNumIdle() - 
> _numInternalProcessing);
> objectDeficit = Math.min(objectDeficit, growLimit);
> }
> if (incrementInternal && objectDeficit >0) {
> _numInternalProcessing++;
> }
> return objectDeficit;
> }
> 
> calculateDeficit method is always return 0.
> So program always throw exception.
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (POOL-190) Add API BaseObjectPool.isOpen()

[Phil Steitz (JIRA)]

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

Phil Steitz closed POOL-190.


> Add API BaseObjectPool.isOpen()
> ---
>
> Key: POOL-190
> URL: https://issues.apache.org/jira/browse/POOL-190
> Project: Commons Pool
>  Issue Type: New Feature
>Affects Versions: 1.5.6
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
> Maven home: C:\Java\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_24\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
> Fix For: 2.0
>
> Attachments: isOpen.diff
>
>
> Add API BaseObjectPool.isOpen()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)