[ANNOUNCEMENT] Apache Commons Pool 2.12.0

[Phil Steitz]

The Apache Commons team is pleased to announce the release of
Apache Commons Pool 2.12.0.

Commons Pool provides an object-pooling API and a number of object pool
implementations.

Java 8 or above is required.

Version 2.12.0 is a maintenance release, including bug fixes and
enhancements.  This release is source and binary compatible with the prior
version, 2.11.1.  All users are encouraged to upgrade.

A complete historical list of changes to Commons Pool is available here:
https://commons.apache.org/proper/commons-pool/changes-report.html

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Pool website:
https://commons.apache.org/proper/commons-pool/

Source and binary distributions are available from the Commons Pool
download page:
https://commons.apache.org/proper/commons-pool/download_pool.cgi

Please verify the hashes and signatures on downloaded artifacts.

The 2.x versions of Commons Pool are distributed under the commons-pool2
maven artifactId. To pull Commons Pool 2.12.0 into an Apache Maven build as
a dependency, use


org.apache.commons
commons-pool2
2.12.0


Thanks in advance for bug reports, suggestions for improvement, patches or
other contributions to the Apache Commons community.

Phil Steitz
-Apache Commons Team

[ANNOUNCE] Apache Commons Pool 2.11.0

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of
Apache Commons Pool 2.11.0.

Apache Commons Pool provides an object-pooling API and a number of
object pool implementations.

Version 2 contains a completely re-written pooling implementation
compared to the 1.x series.
In addition to performance and scalability improvements, version 2
includes robust instance
tracking and pool monitoring.

Version 2.7.x requires Java 8 or above.
Version 2.5.x requires Java 7 or above.
Version 2.0 requires 6 or above.

No client code changes are required to migrate from versions 2.0-2.3
to version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons
Pool web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the
attributes and methods
  that will be made available via JMX. They must not be
implemented by clients as
  they are subject to change between major, minor and patch
version releases of
  Commons Pool. Clients that implement any of these interfaces may
not, therefore,
  be able to upgrade to a new minor or patch release without requiring code
  changes.

This is a feature release (Java 8).

For complete information on Apache Commons Pool, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Apache Commons Pool website:

https://commons.apache.org/proper/commons-pool/

Download page: https://commons.apache.org/proper/commons-pool/download_pool.cgi

Gary Gregory,
Apache Commons Team

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCEMENT] Apache Commons Pool 2.10.0

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of
Apache Commons Pool 2.10.0.

Apache Commons Pool provides an object-pooling API and a number of
object pool implementations.
Version 2 contains a completely re-written pooling implementation
compared to the 1.x series.
In addition to performance and scalability improvements, version 2
includes robust instance
tracking and pool monitoring.

Version 2.10.x requires Java 8 or above.
Version 2.9.x requires Java 8 or above.
Version 2.8.x requires Java 8 or above.
Version 2.7.x requires Java 8 or above.
Version 2.6.x requires Java 7 or above.
Version 2.5.x requires Java 7 or above.
Version 2.0 requires 6 or above.

No client code changes are required to migrate from versions 2.0-2.3
to version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons
Pool web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the
attributes and methods
  that will be made available via JMX. They must not be
implemented by clients as
  they are subject to change between major, minor and patch
version releases of
  Commons Pool. Clients that implement any of these interfaces may
not, therefore,
  be able to upgrade to a new minor or patch release without requiring code
  changes.

This release requires Java 8.

Changes in version 2.10.0 include:

New features:
oAdd and use java.time.Duration APIs timeouts instead of
using ints for seconds.
 See the site and its API comparison report for a list of
the new Duration-based APIs. Thanks to Gary Gregory.
oImplement AbandonedConfig for GenericKeyedObjectPool #67.
Thanks to JSurf, Gary Gregory, Phil Steitz.

Fixed Bugs:
oSimplify Assertions in tests #77. Thanks to Arturo Bernal.
oReplace C-style array declaration with Java style #80.
Thanks to Arturo Bernal.
oUse Objects.equals(); Use Anonymous type; Use method
reference instead Lambda; Replace Loop with Collection.removeIf().
#81. Thanks to Arturo Bernal.
oUse diamond operator. #82. Thanks to Arturo Bernal.
oCode clean ups. #83. Thanks to Arturo Bernal.

Changes:
oBump spotbugs-maven-plugin from 4.0.4 to 4.2.1 #48, #53,
#59, #62. Thanks to Dependabot.
oBump actions/setup-java from v1.4.2 to v2, #47. Thanks to
Dependabot, Gary Gregory.
oBump junit from 4.13 to 4.13.1 #50. Thanks to Dependabot.
oBump biz.aQute.bndlib from 5.1.2 to 5.3.0, #51, #66.
Thanks to Dependabot.
o POOL-389:  Migrate to JUnit 5 #57. Thanks to Arturo Bernal.
o POOL-389:  Minor Improvements #58, #60. Thanks to Arturo Bernal.
oBump actions/checkout from v2.3.3 to v2.3.4 #54. Thanks
to Dependabot.
oBump maven-pmd-plugin from 3.13.0 to 3.14.0 #55. Thanks
to Dependabot.
oUpdate commons.japicmp.version 0.14.3 -> 0.15.3. Thanks
to Gary Gregory.
oBump actions/cache from v2 to v2.1.6 #65, #75, #84.
Thanks to Dependabot, Gary Gregory.
oBump maven-checkstyle-plugin from 3.1.1 to 3.1.2 #61.
Thanks to Dependabot.
oBump asm-util from 9.0 to 9.1 #64. Thanks to Dependabot.
oBump spotbugs from 4.2.1 to 4.2.3 #68, #73, #74. Thanks
to Dependabot.
oBump junit-bom from 5.7.1 to 5.8.0-M1 #76. Thanks to
Dependabot, Gary Gregory.
oBump maven-bundle-plugin from 5.1.1 to 5.1.2 #70. Thanks
to Dependabot.
oBump animal-sniffer-maven-plugin from 1.19 to 1.20.
Thanks to Dependabot.


For complete information on Apache Commons Pool, including
instructions on how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons
Pool website:

https://commons.apache.org/proper/commons-pool/

Download page: https://commons.apache.org/proper/commons-pool/download_pool.cgi
--

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

How to configure DBCP so that connections get closed immediately upon return to the pool

[Igor Mukhin]

Hallo,

Is there a way to configure the DBCP so that connections get closed immediately 
upon return to the pool?
We are using a very strange database connections which are not always reusable. 
So we need to be sure that all connections returned to the pool will not be 
reused. Is there a way to configure it?
(We still would like to use the DBCP because of maxTotal and 
"abandoned"-features)

Mit freundlichen Grüßen
Igor Mukhin




w.e.b.
Wirth EDV Beratung OHG
Jesuitenstrasse 11
85049 Ingolstadt

Telefon +49 (0)841 981280
Telefax +49 (0)841 9812828

http://www.web-dienstleister.de

Sitz der Gesellschaft: Ingolstadt
Registergericht: Amtsgericht Ingolstadt, HRA 1833

[ANNOUNCE] Apache Commons Pool 2.9.0

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.9.0.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring.

Version 2.9.x requires Java 8 or above.
Version 2.8.x requires Java 8 or above.
Version 2.7.x requires Java 8 or above.
Version 2.6.x requires Java 7 or above.
Version 2.5.x requires Java 7 or above.
Version 2.0 requires 6 or above.

No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

This is a minor release (Java 8).

Changes in version 2.9.0 include:

Changes:
o POOL-387:  Object factory destroy method should carry information on
activation context. Thanks to Phil Steitz.
oUpdate spotbugs from 4.0.6 to 4.1.3, #37, #41, #46. Thanks to
Dependabot.
oUpdate actions/checkout from v2.3.1 to v2.3.3 #56, #45. Thanks
to Dependabot.
oUpdate actions/setup-java from v1.4.0 to v1.4.2 #42. Thanks to
Dependabot.
oUpdate optional asm-util from 8.0.1 to 9.0 #44. Thanks to
Dependabot.

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

https://commons.apache.org/proper/commons-pool/

Download page:
https://commons.apache.org/proper/commons-pool/download_pool.cgi

Gary Gregory,
Apache Commons Team

[ANNOUNCEMENT] Apache Commons Pool 2.8.1

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.8.1.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.

No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

This is a maintenance release (Java 8).

Changes in version 2.8.1 include:

New features:
o POOL-385:  Added Automatic-Module-Name to support JPMS #31. Thanks to
scholzi100.

Fixed Bugs:
o POOL-386:  Refactored EvictionTimer usage tracking to fix POOL-386 and
handle abandoned pools. #32. Thanks to Phil Steitz, Mark Thomas.
o[Javadoc] Add missing @throws comment in PoolUtils. #27.
Thanks to Prodigysov, Gary Gregory.

Changes:
o POOL-384:  Update optional library org.ow2.asm:asm-util from 7.2 to
8.0.1. Thanks to Gary Gregory.
oUpdate site reports from org.apache.bcel:bcel 6.4.1 to 6.5.0.
Thanks to Gary Gregory.
oUpdate site reports from maven-pmd-plugin 3.12.0 to 3.13.0.
Thanks to Gary Gregory.
oUpdate build from biz.aQute.bnd:biz.aQute.bndlib 5.1.0 ->
5.1.2. Thanks to Gary Gregory.
oUpdate actions/checkout from v1 to v2.3.1 #33. Thanks to
Dependabot.
oUpdate commons-parent from 50 to 51 #36. Thanks to Dependabot.
oUpdate Checkstyle plugin from 3.0.0 to 3.1.1. Thanks to Gary
Gregory.
oUpdate JApiCmp from 0.14.1 to 0.14.3. Thanks to Gary Gregory.
oUpdate animal-sniffer-maven-plugin from 1.16 to 1.19. Thanks
to Gary Gregory.

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

https://commons.apache.org/proper/commons-pool/

Download page:
https://commons.apache.org/proper/commons-pool/download_pool.cgi

Gary Gregory,
on behalf on the Apache Commons Team

[Pool] Refreshing the pools

[Gardner, Arthur]

Hi!  I am using commons-pool2 to solve this type of problem:

We use a "program" to translate data from one form to another.

The program is in the form of "source code" in a file.  It is inefficient to 
load and "compile" every time we use the feature.

So we give each "program" a name, tied to its file name in the OS.

That name becomes the key in a KeyedObjectPool.

When a new object is needed for the pool, I fetch the code and compile it.

I works great.

Next, of course, somebody wants a way to update the source file, without 
restarting the JVM.

OK, so I figure that pool.clear() or pool.clear(String key) should do the job.

And on my laptop, it does.


Set up a test program and input data, so that I can easily tell what version of 
the program ran, by looking at the output

Single-stepping, get an object (program) with key X, and run on the input

Change the source file

Run the same data, again fetching an object with key X

. as expected, the old output appears - the precompiled program was used from 
the pool

Execute clear() on the pool

Repeat the test a third time

. the output shows that the altered program was used

But on the server, it's not happening.

This in WebSphere 8.5.5 on Red Hat Linux 7,  Java 8.

I am only using commons-pool2-2.4.1 currently ... if I jump too far ahead, I 
can get involved in maven madness, as part of a big company.

There are two apps (.ear files), each with a copy of my jar, so I expect there 
are two pools, and accordingly my reset scripts executes two main() methods, 
one per EAR.

I believe that, by relocating my jar as a WebSphere library, I could end up 
with only one pool, but I don't feel that we need that.

Anyhow, I'm really asking whether anyone has encountered this situation, in 
which you can't really refresh the pools without a jvm restart.

Thanks,
Arthur


The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

[ANNOUNCEMENT] Apache Commons Pool 2.8.0

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.8.0.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.

No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

This is a maintenance release (Java 8).

Changes in version 2.8.0 include:

New features:
o POOL-378:  Deprecate PoolUtils.prefill(ObjectPool, int) in favor of
ObjectPool.addObjects(int). Thanks to Gary Gregory.
o POOL-379:  Deprecate PoolUtils.prefill(KeyedObjectPool, K, int) in favor
of KeyedObjectPool.addObjects(K, int). Thanks to Gary Gregory.
o POOL-380:  Deprecate PoolUtils.prefill(KeyedObjectPool, Collection, int)
in favor of KeyedObjectPool.addObjects(Collection, int). Thanks to Gary
Gregory.

Fixed Bugs:
o POOL-374:
 org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(K, T)
should throw IllegalStateException instead of NullPointerException when a
key is not found in the pool map. Thanks to Gary Gregory, Phil Steitz.
o POOL-376:  Fixed regression from original fix for POOL-356 which could
result in NPE when destroying objects. Thanks to Sazzadul Hoque, Phil
Steitz.
o POOL-326:  Eliminated NPE / ISE exceptions due to keyed pools being
prematurely removed. Thanks to Phil Steitz.
oClose BufferedOutputStream in test before calling toString on
underlying BufferedOutputStream #26. Thanks to emopers.
o[Javadoc] Add missing @throws comment in
SoftReferenceObjectPool. #28. Thanks to Prodigysov.

Changes:
o POOL-375:  Update optional library cglib from 3.2.12 to 3.3.0. Thanks to
Gary Gregory.
oUpdate site build from Apache Commons BCEL 6.3.1 to 6.4.1.
Thanks to Gary Gregory.
o POOL-377:  Update optional library org.ow2.asm:asm-util from 7.1 to 7.2.
Thanks to Gary Gregory.

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

https://commons.apache.org/proper/commons-pool/

Download page:
https://commons.apache.org/proper/commons-pool/download_pool.cgi

Have fun,
Gary

[ANNOUCEMENT] Apache Commons Pool 2.7.0

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.7.0.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.

No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

This is a feature release (Java 8).

Changes in version 2.7.0 include:

New features:
o POOL-370:  Add org.apache.commons.pool2.PooledObject#getBorrowedCount().
Thanks to Mark Thomas, Gary Gregory.
o POOL-371:  Add
org.apache.commons.pool2.PooledObject#setRequireFullStackTrace(boolean).
Thanks to Matt Sicker, Gary Gregory.

Fixed Bugs:
o POOL-361:  Move validation for newly created objects into create(). Fixes
#23. Thanks to Pablo, Phil Steitz, Bruno P. Kinoshita.

Changes:
o POOL-364:  Update from Java 7 to Java 8. Thanks to Gary Gregory.
o POOL-365:  Update ASM from 7.0 to 7.1 Thanks to Gary Gregory.
o POOL-366:  Update optional library cglib from 3.2.10 to 3.2.12. Thanks to
Gary Gregory.
o POOL-367:  Fix typo in package private method name stopEvitor() ->
stopEvictor() #22. Thanks to Per Lundberg.

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

https://commons.apache.org/proper/commons-pool/

Download page:
https://commons.apache.org/proper/commons-pool/download_pool.cgi

Gary Gregory
On behalf of the Apache Commons Team

[ANNOUCE] Apache Commons Pool 2.6.2

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.6.2.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.

No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

This is a maintenance release.

Changes in version 2.6.2 include:

Fixed Bugs:
o POOL-362:  Always null out
org.apache.commons.pool2.impl.BaseGenericObjectPool.evictionIterator to
match org.apache.commons.pool2.impl.BaseGenericObjectPool.evictor.
o POOL-363:  Evictor Thread prevents Spring Context shutdown in standalone
app. Thanks to Josh Landin.
o POOL-348:  The commons-pool-evictor-thread should run as a Deamon. Thanks
to Josh Landin.

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

http://commons.apache.org/proper/commons-pool/

Download page:
http://commons.apache.org/proper/commons-pool/download_pool.cgi

Gary Gregory,
On behalf of the Apache Commons community

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Bruce Milner]

On 9/9/2018 12:16 AM, Mark Thomas wrote:

On 08/09/18 19:36, Mark Thomas wrote:




For the "- parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155.
Though I see no other messages with that object in the thread dump.

Has anyone run into this? It seems like some sort of deadlock.

Do you still have the full thread dump? Can you post it somewhere (where
we can look at it)?

Thanks. Lots of threads waiting for the lock. None holding it. That is
very strange.

Some variation of this?

https://confluence.atlassian.com/jirakb/jira-applications-stall-due-to-stackoverflowerror-exception-941601100.html

Mark

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Yeah, I looked closer at thread dump and no thread holding lock. Also 
looked in past several months of logs and no StackOverflowError's .

My guess now is JVM bug.

Thanks for looking!

--bruce

--
Bruce Milner
Senior Software Developer (Emberex)


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Phil Steitz]

On 9/9/18 12:16 AM, Mark Thomas wrote:

On 08/09/18 19:36, Mark Thomas wrote:




For the "- parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155.
Though I see no other messages with that object in the thread dump.

Has anyone run into this? It seems like some sort of deadlock.

Do you still have the full thread dump? Can you post it somewhere (where
we can look at it)?

Thanks. Lots of threads waiting for the lock. None holding it. That is
very strange.

Some variation of this?

https://confluence.atlassian.com/jirakb/jira-applications-stall-due-to-stackoverflowerror-exception-941601100.html

Here is one thing to look at.  Note that the take request from 
borrowObject comes from

p = objectDeque.getIdleObjects().pollFirst();

This LinkedBlockingDeque method does not register the thread as 
waiting on the notEmpty condition in LinkedBlockingDeque the way 
that say

 p = objectDeque.getIdleObjects().pollFirst(
    borrowMaxWaitMillis, 
TimeUnit.MILLISECONDS);

does.

Phil


Mark

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Mark Thomas]

On 08/09/18 19:36, Mark Thomas wrote:



>> For the "- parking to wait for  <0x0006471cd7d8> (a
>> java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155.
>> Though I see no other messages with that object in the thread dump.
>>
>> Has anyone run into this? It seems like some sort of deadlock.
> 
> Do you still have the full thread dump? Can you post it somewhere (where
> we can look at it)?

Thanks. Lots of threads waiting for the lock. None holding it. That is
very strange.

Some variation of this?

https://confluence.atlassian.com/jirakb/jira-applications-stall-due-to-stackoverflowerror-exception-941601100.html

Mark

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Bruce Milner]

Hello Mark,

I sent the thread dump directly to you.

On 9/8/2018 11:36 AM, Mark Thomas wrote:

On 07/09/18 22:56, Bruce Milner wrote:

Hello,

I am using commons-pool2-2.5.0 for a MySQL connection pooler. The reason
for not using out-of-the-box is that the existing code relies on
changing catalogs at runtime reusing an existing connection. The
original design was to use multiple databases using the same connection
and this cannot be changed.

I recently replaced a lot of hand crafted code with the commons-pool2
implementation.

The issue I have is that one server I manage went into a state where
there are plenty of connections, but none are being returned to the
pool. They are all stuck on a lock inside of
GenericKeyedObjectPool.returnObject.

The config is basically
     GenericKeyedObjectPoolConfig config = new
GenericKeyedObjectPoolConfig();
     config.setBlockWhenExhausted(true);
     config.setMaxTotal(120);
     config.setMaxTotalPerKey(60);
     config.setTestOnBorrow(true);
     config.setTimeBetweenEvictionRunsMillis(6);
     config.setMinEvictableIdleTimeMillis(0); // don't starve
connections because of catalog switches.
     /**
  * For database connections, use FIFO so that we get rid of
older connections first before newer ones.
  */
     config.setLifo(false);
     return new GenericKeyedObjectPool(new
PooledConnectionFactory(), config);

There are 150 of these threads waiting on a lock to release connections
    java.lang.Thread.State: WAITING (parking)
     at sun.misc.Unsafe.park(Native Method)
     - parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
     at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)

     at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)

     at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)

     at
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)

     at
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
     at
org.apache.commons.pool2.impl.LinkedBlockingDeque.hasTakeWaiters(LinkedBlockingDeque.java:1389)

     at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.hasBorrowWaiters(GenericKeyedObjectPool.java:849)

     at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:551)

     at
com.ilrn.util.sql.connectionpooler.ConnectionPooler.releaseConnection(ConnectionPooler.java:358)

     at
com.ilrn.util.sql.connectionpooler.PooledConnection.close(PooledConnection.java:141)

     at
com.ilrn.util.sql.connectionpooler.ConnectionPooler.safeClose(ConnectionPooler.java:480)


and 158 of these threads waiting to open connections.
  java.lang.Thread.State: WAITING (parking)
     at sun.misc.Unsafe.park(Native Method)
     - parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
     at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)

     at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)

     at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)

     at
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)

     at
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
     at
org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:560)

     at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:356)

     at
org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:281)

     at
com.ilrn.util.sql.connectionpooler.ConnectionPooler.getConnection(ConnectionPooler.java:197)

     at com.ilrn.util.sql.Database.getConnection(Database.java:1273)

For the "- parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155.
Though I see no other messages with that object in the thread dump.

Has anyone run into this? It seems like some sort of deadlock.

Do you still have the full thread dump? Can you post it somewhere (where
we can look at it)?

Mark



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



--
Bruce Milner
Senior Software Developer (Emberex)


-
To unsubscribe, e-mail: user-unsubscr...@commo

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Bernd Eckenfels]

Hello Bruce,

This sounds a bit like a discussion we had about missing wakeups. I think it’s 
was related to depleted pools. Didn’t find the discussion, hopefully somebody 
else recalls the conditions? I think it was not fixed.

Gruss
Bernd
--
http://bernd.eckenfels.net


Von: Bruce Milner 
Gesendet: Samstag, September 8, 2018 8:19 PM
An: user@commons.apache.org
Betreff: Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

Hello,

I did a while back, but my understanding of DBCP is that it has one pool
per database and we have thousands.

With the number of nodes serving the application multiplied by the
number of databases, it could easily exceed maximum number of
connections to existing SQL database server. The individual databases
are mostly shared by one database server each have individual schemas.
We keep track of the database URL and switch the connection via
connector.setCatalog(). We also have some that co-exist, so the
connection pool has the smarts to decide if it needs a catalog change.

The commons pool has been working great so far, and this is the only
case I have see where we ended up in this state. We haven't seen this
with load tests, but this once in production.

I was hoping if this exposed a bug, could get fixed in the pool code. I
don't have a reproduction case at this time. I forgot to mention that
the environment is java 8 141 with Connector/J 5.1.45

--bruce

On 9/7/2018 5:05 PM, Gary Gregory wrote:
> Hi,
>
> A side question: Have you tried Apache Commons DBCP (which is based on
> Commons Pool)?
>
> https://commons.apache.org/proper/commons-dbcp/
>
> Gary
>
> On Fri, Sep 7, 2018 at 5:24 PM Bruce Milner 
> wrote:
>
>> Hello,
>>
>> I am using commons-pool2-2.5.0 for a MySQL connection pooler. The reason
>> for not using out-of-the-box is that the existing code relies on
>> changing catalogs at runtime reusing an existing connection. The
>> original design was to use multiple databases using the same connection
>> and this cannot be changed.
>>
>> I recently replaced a lot of hand crafted code with the commons-pool2
>> implementation.
>>
>> The issue I have is that one server I manage went into a state where
>> there are plenty of connections, but none are being returned to the
>> pool. They are all stuck on a lock inside of
>> GenericKeyedObjectPool.returnObject.
>>
>> The config is basically
>> GenericKeyedObjectPoolConfig config = new
>> GenericKeyedObjectPoolConfig();
>> config.setBlockWhenExhausted(true);
>> config.setMaxTotal(120);
>> config.setMaxTotalPerKey(60);
>> config.setTestOnBorrow(true);
>> config.setTimeBetweenEvictionRunsMillis(6);
>> config.setMinEvictableIdleTimeMillis(0); // don't starve
>> connections because of catalog switches.
>> /**
>> * For database connections, use FIFO so that we get rid of
>> older connections first before newer ones.
>> */
>> config.setLifo(false);
>> return new GenericKeyedObjectPool(new
>> PooledConnectionFactory(), config);
>>
>> There are 150 of these threads waiting on a lock to release connections
>> java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for <0x0006471cd7d8> (a
>> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> at
>>
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>> at
>>
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
>> at
>>
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
>> at
>>
>> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
>> at
>> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>> at
>>
>> org.apache.commons.pool2.impl.LinkedBlockingDeque.hasTakeWaiters(LinkedBlockingDeque.java:1389)
>> at
>>
>> org.apache.commons.pool2.impl.GenericKeyedObjectPool.hasBorrowWaiters(GenericKeyedObjectPool.java:849)
>> at
>>
>> org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:551)
>> at
>>
>> com.ilrn.util.sql.connectionpooler.ConnectionPooler.releaseConnection(ConnectionPooler.java:358)
>> at
>>
>> com.ilrn.util.sql.connectionpooler.PooledConnection.close(PooledConnection.java:141)
>> at
>>
>> com.ilrn.util.sql.connectionpooler.ConnectionPooler.safeClose(C

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Mark Thomas]

On 07/09/18 22:56, Bruce Milner wrote:
> Hello,
> 
> I am using commons-pool2-2.5.0 for a MySQL connection pooler. The reason
> for not using out-of-the-box is that the existing code relies on
> changing catalogs at runtime reusing an existing connection. The
> original design was to use multiple databases using the same connection
> and this cannot be changed.
> 
> I recently replaced a lot of hand crafted code with the commons-pool2
> implementation.
> 
> The issue I have is that one server I manage went into a state where
> there are plenty of connections, but none are being returned to the
> pool. They are all stuck on a lock inside of
> GenericKeyedObjectPool.returnObject.
> 
> The config is basically
>     GenericKeyedObjectPoolConfig config = new
> GenericKeyedObjectPoolConfig();
>     config.setBlockWhenExhausted(true);
>     config.setMaxTotal(120);
>     config.setMaxTotalPerKey(60);
>     config.setTestOnBorrow(true);
>     config.setTimeBetweenEvictionRunsMillis(6);
>     config.setMinEvictableIdleTimeMillis(0); // don't starve
> connections because of catalog switches.
>     /**
>  * For database connections, use FIFO so that we get rid of
> older connections first before newer ones.
>  */
>     config.setLifo(false);
>     return new GenericKeyedObjectPool(new
> PooledConnectionFactory(), config);
> 
> There are 150 of these threads waiting on a lock to release connections
>    java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for  <0x0006471cd7d8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> 
>     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> 
>     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> 
>     at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> 
>     at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>     at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.hasTakeWaiters(LinkedBlockingDeque.java:1389)
> 
>     at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.hasBorrowWaiters(GenericKeyedObjectPool.java:849)
> 
>     at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:551)
> 
>     at
> com.ilrn.util.sql.connectionpooler.ConnectionPooler.releaseConnection(ConnectionPooler.java:358)
> 
>     at
> com.ilrn.util.sql.connectionpooler.PooledConnection.close(PooledConnection.java:141)
> 
>     at
> com.ilrn.util.sql.connectionpooler.ConnectionPooler.safeClose(ConnectionPooler.java:480)
> 
> 
> and 158 of these threads waiting to open connections.
>  java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for  <0x0006471cd7d8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>     at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> 
>     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> 
>     at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> 
>     at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> 
>     at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>     at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:560)
> 
>     at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:356)
> 
>     at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:281)
> 
>     at
> com.ilrn.util.sql.connectionpooler.ConnectionPooler.getConnection(ConnectionPooler.java:197)
> 
>     at com.ilrn.util.sql.Database.getConnection(Database.java:1273)
> 
> For the "- parking to wait for  <0x0006471cd7d8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155.
> Though I see no other messages with that object in the thread dump.
> 
> Has anyone run into this? It seems like some sort of deadlock.

Do you still have the full thread dump? Can you post it somewhere (where
we can look at it)?

Mark



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Bruce Milner]

Hello,

I did a while back, but my understanding of DBCP is that it has one pool 
per database and we have thousands.


With the number of nodes serving the application multiplied by the 
number of databases, it could easily exceed maximum number of 
connections to existing SQL database server. The individual databases 
are mostly shared by one database server each have individual schemas. 
We keep track of the database URL and switch the connection via 
connector.setCatalog(). We also have some that co-exist, so the 
connection pool has the smarts to decide if it needs a catalog change.


The commons pool has been working great so far, and this is the only 
case I have see where we ended up in this state. We haven't seen this 
with load tests, but this once in production.


I was hoping if this exposed a bug, could get fixed in the pool code. I 
don't have a reproduction case at this time. I forgot to mention that 
the environment is java 8 141 with Connector/J 5.1.45


--bruce

On 9/7/2018 5:05 PM, Gary Gregory wrote:

Hi,

A side question: Have you tried Apache Commons DBCP (which is based on
Commons Pool)?

https://commons.apache.org/proper/commons-dbcp/

Gary

On Fri, Sep 7, 2018 at 5:24 PM Bruce Milner 
wrote:


Hello,

I am using commons-pool2-2.5.0 for a MySQL connection pooler. The reason
for not using out-of-the-box is that the existing code relies on
changing catalogs at runtime reusing an existing connection. The
original design was to use multiple databases using the same connection
and this cannot be changed.

I recently replaced a lot of hand crafted code with the commons-pool2
implementation.

The issue I have is that one server I manage went into a state where
there are plenty of connections, but none are being returned to the
pool. They are all stuck on a lock inside of
GenericKeyedObjectPool.returnObject.

The config is basically
  GenericKeyedObjectPoolConfig config = new
GenericKeyedObjectPoolConfig();
  config.setBlockWhenExhausted(true);
  config.setMaxTotal(120);
  config.setMaxTotalPerKey(60);
  config.setTestOnBorrow(true);
  config.setTimeBetweenEvictionRunsMillis(6);
  config.setMinEvictableIdleTimeMillis(0); // don't starve
connections because of catalog switches.
  /**
   * For database connections, use FIFO so that we get rid of
older connections first before newer ones.
   */
  config.setLifo(false);
  return new GenericKeyedObjectPool(new
PooledConnectionFactory(), config);

There are 150 of these threads waiting on a lock to release connections
 java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at

java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
  at

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
  at

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
  at

java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
  at
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
  at

org.apache.commons.pool2.impl.LinkedBlockingDeque.hasTakeWaiters(LinkedBlockingDeque.java:1389)
  at

org.apache.commons.pool2.impl.GenericKeyedObjectPool.hasBorrowWaiters(GenericKeyedObjectPool.java:849)
  at

org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:551)
  at

com.ilrn.util.sql.connectionpooler.ConnectionPooler.releaseConnection(ConnectionPooler.java:358)
  at

com.ilrn.util.sql.connectionpooler.PooledConnection.close(PooledConnection.java:141)
  at

com.ilrn.util.sql.connectionpooler.ConnectionPooler.safeClose(ConnectionPooler.java:480)

and 158 of these threads waiting to open connections.
   java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x0006471cd7d8> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at

java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
  at

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
  at

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
  at

java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
  at
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
  at

org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(LinkedBlockingDe

Re: [pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Gary Gregory]

Hi,

A side question: Have you tried Apache Commons DBCP (which is based on
Commons Pool)?

https://commons.apache.org/proper/commons-dbcp/

Gary

On Fri, Sep 7, 2018 at 5:24 PM Bruce Milner 
wrote:

> Hello,
>
> I am using commons-pool2-2.5.0 for a MySQL connection pooler. The reason
> for not using out-of-the-box is that the existing code relies on
> changing catalogs at runtime reusing an existing connection. The
> original design was to use multiple databases using the same connection
> and this cannot be changed.
>
> I recently replaced a lot of hand crafted code with the commons-pool2
> implementation.
>
> The issue I have is that one server I manage went into a state where
> there are plenty of connections, but none are being returned to the
> pool. They are all stuck on a lock inside of
> GenericKeyedObjectPool.returnObject.
>
> The config is basically
>  GenericKeyedObjectPoolConfig config = new
> GenericKeyedObjectPoolConfig();
>  config.setBlockWhenExhausted(true);
>  config.setMaxTotal(120);
>  config.setMaxTotalPerKey(60);
>  config.setTestOnBorrow(true);
>  config.setTimeBetweenEvictionRunsMillis(6);
>  config.setMinEvictableIdleTimeMillis(0); // don't starve
> connections because of catalog switches.
>  /**
>   * For database connections, use FIFO so that we get rid of
> older connections first before newer ones.
>   */
>  config.setLifo(false);
>  return new GenericKeyedObjectPool(new
> PooledConnectionFactory(), config);
>
> There are 150 of these threads waiting on a lock to release connections
> java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for  <0x0006471cd7d8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>  at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
>  at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
>  at
>
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
>  at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>  at
>
> org.apache.commons.pool2.impl.LinkedBlockingDeque.hasTakeWaiters(LinkedBlockingDeque.java:1389)
>  at
>
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.hasBorrowWaiters(GenericKeyedObjectPool.java:849)
>  at
>
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:551)
>  at
>
> com.ilrn.util.sql.connectionpooler.ConnectionPooler.releaseConnection(ConnectionPooler.java:358)
>  at
>
> com.ilrn.util.sql.connectionpooler.PooledConnection.close(PooledConnection.java:141)
>  at
>
> com.ilrn.util.sql.connectionpooler.ConnectionPooler.safeClose(ConnectionPooler.java:480)
>
> and 158 of these threads waiting to open connections.
>   java.lang.Thread.State: WAITING (parking)
>  at sun.misc.Unsafe.park(Native Method)
>  - parking to wait for  <0x0006471cd7d8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
>  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>  at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>  at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
>  at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
>  at
>
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
>  at
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>  at
>
> org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:560)
>  at
>
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:356)
>  at
>
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:281)
>  at
>
> com.ilrn.util.sql.connectionpooler.ConnectionPooler.getConnection(ConnectionPooler.java:197)
>  at com.ilrn.util.sql.Database.getConnection(Database.java:1273)
>
> For the "- parking to wait for  <0x0006471cd7d8> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155.
> Though I see n

[pool] Possible deadlock or user error (me) commons-pool 2.5.0

[Bruce Milner]

Hello,

I am using commons-pool2-2.5.0 for a MySQL connection pooler. The reason 
for not using out-of-the-box is that the existing code relies on 
changing catalogs at runtime reusing an existing connection. The 
original design was to use multiple databases using the same connection 
and this cannot be changed.


I recently replaced a lot of hand crafted code with the commons-pool2 
implementation.


The issue I have is that one server I manage went into a state where 
there are plenty of connections, but none are being returned to the 
pool. They are all stuck on a lock inside of 
GenericKeyedObjectPool.returnObject.


The config is basically
    GenericKeyedObjectPoolConfig config = new 
GenericKeyedObjectPoolConfig();

    config.setBlockWhenExhausted(true);
    config.setMaxTotal(120);
    config.setMaxTotalPerKey(60);
    config.setTestOnBorrow(true);
    config.setTimeBetweenEvictionRunsMillis(6);
    config.setMinEvictableIdleTimeMillis(0); // don't starve 
connections because of catalog switches.

    /**
 * For database connections, use FIFO so that we get rid of 
older connections first before newer ones.

 */
    config.setLifo(false);
    return new GenericKeyedObjectPool(new 
PooledConnectionFactory(), config);


There are 150 of these threads waiting on a lock to release connections
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0006471cd7d8> (a 
java.util.concurrent.locks.ReentrantLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
    at 
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
    at 
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
    at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.hasTakeWaiters(LinkedBlockingDeque.java:1389)
    at 
org.apache.commons.pool2.impl.GenericKeyedObjectPool.hasBorrowWaiters(GenericKeyedObjectPool.java:849)
    at 
org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:551)
    at 
com.ilrn.util.sql.connectionpooler.ConnectionPooler.releaseConnection(ConnectionPooler.java:358)
    at 
com.ilrn.util.sql.connectionpooler.PooledConnection.close(PooledConnection.java:141)
    at 
com.ilrn.util.sql.connectionpooler.ConnectionPooler.safeClose(ConnectionPooler.java:480)


and 158 of these threads waiting to open connections.
 java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0006471cd7d8> (a 
java.util.concurrent.locks.ReentrantLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
    at 
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
    at 
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
    at 
org.apache.commons.pool2.impl.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:560)
    at 
org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:356)
    at 
org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:281)
    at 
com.ilrn.util.sql.connectionpooler.ConnectionPooler.getConnection(ConnectionPooler.java:197)

    at com.ilrn.util.sql.Database.getConnection(Database.java:1273)

For the "- parking to wait for  <0x0006471cd7d8> (a 
java.util.concurrent.locks.ReentrantLock$NonfairSync)" there are 155. 
Though I see no other messages with that object in the thread dump.


Has anyone run into this? It seems like some sort of deadlock.

--
Bruce Milner
Senior Software Developer (Emberex)


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCEMENT] Apache Commons Pool 2.6.0 released.

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.6.0.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring.

- Version 2.6.0 requires Java 7 or above.
- Version 2.5.0 requires Java 7 or above.
- Version 2.0 requires 6 or above.

No client code changes are required to migrate from versions 2.0-2.3 to
version 2.4.3.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

This is a maintenance release.

Changes in version 2.6.0 include:

Fixed Bugs:
o POOL-337:  Ensure cancelled eviction tasks are removed from scheduler.
Thanks to Reinald Verheij.
o POOL-338:  GenericObjectPool constructor may throw an exception under
OSGi. Thanks to Michael C, Gary Gregory.
o POOL-324:
org.apache.commons.pool2.impl.GenericObjectPool.getFactoryType() throws
java.lang.ClassCastException. Thanks to Jay Xu, Gary Gregory.
o POOL-344:  Delete repeated call startEvictor. Thanks to Yulin Wang.

Changes:
o POOL-336:  GenericObjectPool's borrowObject lock if create() fails with
Error. Thanks to Wolfgang Glas.
o POOL-339:  Update optional library cglib from 3.2.5 to 3.2.6.
o POOL-341:  Update optional library asm-util from 6.0 to 6.1.1.
o POOL-342:  Update optional library asm-util from 6.1.1 to 6.2.

Note that Clirr reports one warning:
"Value of field DEFAULT_EVICTION_POLICY_CLASS_NAME is no longer a
compile-time constant."
The value is initialized as "public static final String
DEFAULT_EVICTION_POLICY_CLASS_NAME = DefaultEvictionPolicy.class.getName();"
The value should not change from one run to the next.

For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

http://commons.apache.org/proper/commons-pool/

Gary Gregory
On behalf of the Apache Commons community

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Bernd Eckenfels]

I think it is best you direct your tomcat pool related questions and comments 
about their documentation to the tomcat mailing lists. (On the other hand the 
tomcat documentation on their own pool including a description why they don't 
use dbcp 1.x looks rather comprehensive to me: 
https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Introduction)

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Shawn Heisey <apa...@elyograg.org>
Sent: Saturday, March 24, 2018 2:09:59 AM
To: user@commons.apache.org
Subject: Re: [DBCP] troubleshooting pool activity (tomcat version)

On 3/23/2018 5:19 PM, Phil Steitz wrote:
> That's the documentation for the alternative pool.  Use this instead:
> https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP)_Configurations

This does not really explain how to configure Tomcat.  It says "go see
the DBCP documentation for parameters you can use."  I do see some
Resource configurationsfurther down on the page ... and they do not have
a "factory" attribute at all.  Is that the difference?

The only resource I have is Tomcat documentation, and whatever nuggets
were *left out* of the Tomcat documentation that I might learn here.  If
this were source code, I could get it all working.  Especially using
DBCP2.  But there's no code for me to modify -- I only have Resource
configurations in tomcat's context.xml file.

Since there doesn't appear to be any documentation for setting it up the
way you think I should be setting it up ... can you guide me to writing
a new configuration?

The config I'm planning has evolved a little bit since the last time I
shared it.  Here's an example of its current state:



If you think I should be doing something different, please tell me
exactly what you think I should change, and tell me *why* you think each
of those changes is a good idea.  And then maybe I can discuss
documentation deficiencies with the Tomcat community.


> Yes, that is a borrow.
> There is another, um, "feature" that I forgot to mention in ye olde
> DBCP 1.x.  As documented here
> https://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/BasicDataSource.html#getRemoveAbandoned()
> removal will only happen with your config if there are 57+
> connections out.

That seems like a REALLY bad way to handle it!  Hopefully that's changed
in the newest 1.x and 2.x versions!

Does this affect Tomcat too?  How about the
"org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" that we currently
have configured?  I was planning to use abandonWhenPercentageFull="50",
which is specific to Tomcat.  The property description looks like it
will fix that issue.  I think I'll just leave it out, which the
documentation says will make connections ALWAYS eligible for removal
once they've reached the abandoned timeout.

Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Shawn Heisey]

On 3/23/2018 5:19 PM, Phil Steitz wrote:
> That's the documentation for the alternative pool.  Use this instead:
> https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP)_Configurations

This does not really explain how to configure Tomcat.  It says "go see
the DBCP documentation for parameters you can use."  I do see some
Resource configurationsfurther down on the page ... and they do not have
a "factory" attribute at all.  Is that the difference?

The only resource I have is Tomcat documentation, and whatever nuggets
were *left out* of the Tomcat documentation that I might learn here.  If
this were source code, I could get it all working.  Especially using
DBCP2.  But there's no code for me to modify -- I only have Resource
configurations in tomcat's context.xml file.

Since there doesn't appear to be any documentation for setting it up the
way you think I should be setting it up ... can you guide me to writing
a new configuration?

The config I'm planning has evolved a little bit since the last time I
shared it.  Here's an example of its current state:

    

If you think I should be doing something different, please tell me
exactly what you think I should change, and tell me *why* you think each
of those changes is a good idea.  And then maybe I can discuss
documentation deficiencies with the Tomcat community.


> Yes, that is a borrow.
> There is another, um, "feature" that I forgot to mention in ye olde
> DBCP 1.x.  As documented here
> https://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/BasicDataSource.html#getRemoveAbandoned()
> removal will only happen with your config if there are 57+
> connections out.

That seems like a REALLY bad way to handle it!  Hopefully that's changed
in the newest 1.x and 2.x versions!

Does this affect Tomcat too?  How about the
"org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" that we currently
have configured?  I was planning to use abandonWhenPercentageFull="50",
which is specific to Tomcat.  The property description looks like it
will fix that issue.  I think I'll just leave it out, which the
documentation says will make connections ALWAYS eligible for removal
once they've reached the abandoned timeout.

Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Phil Steitz]

On 3/22/18 6:14 PM, Shawn Heisey wrote:
> First thing to do is thank you again for taking the time to help me. 
> Apache has great communities.
>
> On 3/22/2018 5:38 PM, Phil Steitz wrote:
>> You must be looking at documentation describing how to use the
>> alternative pool mentioned above (tomcat-jdbc).  The config you
>> posted is correct for DBCP.
> I'm looking at Tomcat documentation.
>
> https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

That's the documentation for the alternative pool.  Use this instead:
https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP)_Configurations

>
> The tomcat is the one included with Liferay 6.2.  It is 7.0.42.

>From here
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_42/build.properties.default

You can see the bundled DBCP / Pool are 1.4/1.5.7 which are the
latest compatible versions.
>
>> Don't look at DBCP 2 code for troubleshooting the code you are
>> running.  Either look at the repackaged sources inside the tomcat
>> source, or find the version in the tomcat build files and go to the
>> old DBCP / pool sources referenced there.
> I have figured that out.  Felt pretty dumb when I realized I wasn't
> looking at code from the correct Tomcat version.
>
>> Of course, you *should* upgrade both TC and the DBCP it ships so you
>> *can* look at that (much better) code.  See below for one reason why.
> I hear what you're saying, and don't disagree ... but this is not the
> kind of environment where I can just do an upgrade, even though
> upgrading might make it all better.
>
> We didn't download Tomcat -- we downloaded Liferay, which came with a
> specific version of Tomcat already included.  Upgrading any significant
> component (liferay, tomcat, and others) runs the risk that when we
> restart the service, our web application won't work any more.  For any
> upgrade, we have to spend a lot of resources trying the upgrade in a
> staging environment, so we can be sure that everything still works. 
> Because that's very time-consuming, we tend to not do a lot of
> upgrading, at least of significant components, and our versions get
> REALLY old.
>
> This is also why I'm hesitant to move away from Tomcat's DBCP
> implementation to Commons DBCP (particularly version 2), even though
> that's exactly what I want to do.  Switching to a different library
> might work seamlessly ... or it might completely break the application. 
> Our customers get REALLY irritated when the websites we've built for
> them don't work!

Using DBCP2 with TC 7 won't work.  You need TC 8+ for that.
>
>> One thing that could be going on is that in the old 1.x DBCP, 
>> abandoned connection removal only happens when borrows are
>> attempted.  So if you check out a lot of connections, abandon them
>> and don't ask for more, they won't get closed as abandoned until you
>> borrow a new one.  In DBCP 2, the removeAbandoned property is split
>> into two different properties:  removeAbandonedOnBorrow (the old
>> behavior) and removeAbandonedOnMaintenance.  The second one makes
>> abandoned connection removal run on pool maintenance (so will not
>> have to wait until a borrow is attempted).
> I don't know if anyone needs me to actually back up and describe what's
> happening that led me down this rabbit hole, but that's what I'm going
> to do:
>
> The master MySQL server in our environment has a max connection limit
> configured at 600 connections.
>
> Every now and then, we start getting website failures, because all the
> connections are in use and the connection pools can't make any more
> connections.  Looking at the connections on the MySQL side, the vast
> majority are idle (the command is "Sleep" on the server processlist),
> and have been idle for several hours.
>
> There are five main webservers and a handful of ancillary systems that
> also connect to the database.  When the problem happens, the connection
> count from each webserver has gotten up near 100, and sometimes over
> 100.  The surplus of connections are definitely the ones configured in
> Tomcat.  Liferay has its own DB config for its own data (using c3p0 for
> pooling), and although I often see a higher number of connections to
> that database than I would excpect, I've never seen the idle time on
> those connections above one minute, so I'm not concerned about that
> pool, beyond some minor tweaks.
>
> The frequency of the connection-related failures has been increasing, so
> in response, I have set up monitoring that will send us an alarm when
> the server reaches 550 connections.  This has allowed us to kill idle
> connections and prevent customer-visible pr

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Shawn Heisey]

First thing to do is thank you again for taking the time to help me. 
Apache has great communities.

On 3/22/2018 5:38 PM, Phil Steitz wrote:
> You must be looking at documentation describing how to use the
> alternative pool mentioned above (tomcat-jdbc).  The config you
> posted is correct for DBCP.

I'm looking at Tomcat documentation.

https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html

The tomcat is the one included with Liferay 6.2.  It is 7.0.42.

> Don't look at DBCP 2 code for troubleshooting the code you are
> running.  Either look at the repackaged sources inside the tomcat
> source, or find the version in the tomcat build files and go to the
> old DBCP / pool sources referenced there.

I have figured that out.  Felt pretty dumb when I realized I wasn't
looking at code from the correct Tomcat version.

> Of course, you *should* upgrade both TC and the DBCP it ships so you
> *can* look at that (much better) code.  See below for one reason why.

I hear what you're saying, and don't disagree ... but this is not the
kind of environment where I can just do an upgrade, even though
upgrading might make it all better.

We didn't download Tomcat -- we downloaded Liferay, which came with a
specific version of Tomcat already included.  Upgrading any significant
component (liferay, tomcat, and others) runs the risk that when we
restart the service, our web application won't work any more.  For any
upgrade, we have to spend a lot of resources trying the upgrade in a
staging environment, so we can be sure that everything still works. 
Because that's very time-consuming, we tend to not do a lot of
upgrading, at least of significant components, and our versions get
REALLY old.

This is also why I'm hesitant to move away from Tomcat's DBCP
implementation to Commons DBCP (particularly version 2), even though
that's exactly what I want to do.  Switching to a different library
might work seamlessly ... or it might completely break the application. 
Our customers get REALLY irritated when the websites we've built for
them don't work!

> One thing that could be going on is that in the old 1.x DBCP, 
> abandoned connection removal only happens when borrows are
> attempted.  So if you check out a lot of connections, abandon them
> and don't ask for more, they won't get closed as abandoned until you
> borrow a new one.  In DBCP 2, the removeAbandoned property is split
> into two different properties:  removeAbandonedOnBorrow (the old
> behavior) and removeAbandonedOnMaintenance.  The second one makes
> abandoned connection removal run on pool maintenance (so will not
> have to wait until a borrow is attempted).

I don't know if anyone needs me to actually back up and describe what's
happening that led me down this rabbit hole, but that's what I'm going
to do:

The master MySQL server in our environment has a max connection limit
configured at 600 connections.

Every now and then, we start getting website failures, because all the
connections are in use and the connection pools can't make any more
connections.  Looking at the connections on the MySQL side, the vast
majority are idle (the command is "Sleep" on the server processlist),
and have been idle for several hours.

There are five main webservers and a handful of ancillary systems that
also connect to the database.  When the problem happens, the connection
count from each webserver has gotten up near 100, and sometimes over
100.  The surplus of connections are definitely the ones configured in
Tomcat.  Liferay has its own DB config for its own data (using c3p0 for
pooling), and although I often see a higher number of connections to
that database than I would excpect, I've never seen the idle time on
those connections above one minute, so I'm not concerned about that
pool, beyond some minor tweaks.

The frequency of the connection-related failures has been increasing, so
in response, I have set up monitoring that will send us an alarm when
the server reaches 550 connections.  This has allowed us to kill idle
connections and prevent customer-visible problems a couple of times
already, but we still have a fundamental issue to correct.

I do not yet have any information that indicates whether Tomcat's DBCP
thinks those connections are idle or active.  I have reason to suspect
that they are active, and have not been returned to the pool (closed). 
I've worked out a way with one of our developers to add logging that
displays the active and idle connection counts, but it's not yet in
production.  If those connections were idle, as the MySQL server thinks
they are, it really seems like DBCP would be choosing to re-use a
connection that it's already got, instead of trying to create a brand
new one and failing.

So I am chasing abandoned connection removal.  We have it configured,
but it's not working.  The config is lacking things I think it needs,
but as far as I could tell, there is enough for abandoned

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Phil Steitz]

On 3/21/18 12:15 PM, Shawn Heisey wrote:
> On 3/21/2018 1:31 AM, Mark Thomas wrote:
>>> and that we need to
>>> change the factory on our pool definitions.
>> I believe not.
> Tomcat's documentation seems to disagree with this point. It
> specifically says to use org.apache.tomcat.jdbc.pool.DataSourceFactory,
> and doesn't list any other valid choices.

You must be looking at documentation describing how to use the
alternative pool mentioned above (tomcat-jdbc).  The config you
posted is correct for DBCP.

> But we have
> org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory in our
> configuration.  I've found questions from people whose Tomcat
> installations didn't even contain that class, where the answers said to
> switch to the factory in the documentation.  Apparently deb-based
> packages of Tomcat do not contain the latter class.
>
> I found a historical document for 7.0.42 with Google and it also shows
> that the factory should be set to the DataSourceFactory, not the
> BasicDataSourceFactory that we have.
>
> I do see "removeAbandoned" in the property constants in the 7.0 source
> code for BasicDataSourceFactory  I had thought that it wasn't there,
> but I realized that I was looking at trunk code when I came to that
> conclusion, and that BasicDataSourceFactory is in a dbcp2 package in
> trunk.  
Don't look at DBCP 2 code for troubleshooting the code you are
running.  Either look at the repackaged sources inside the tomcat
source, or find the version in the tomcat build files and go to the
old DBCP / pool sources referenced there.

Of course, you *should* upgrade both TC and the DBCP it ships so you
*can* look at that (much better) code.  See below for one reason why.
> So I'm not sure what to think, but I can say that the abandoned
> connection handling does not appear to actually be working.  So either
> my configuration is wrong, or the factory that we are using is ignoring
> part of the config.

One thing that could be going on is that in the old 1.x DBCP, 
abandoned connection removal only happens when borrows are
attempted.  So if you check out a lot of connections, abandon them
and don't ask for more, they won't get closed as abandoned until you
borrow a new one.  In DBCP 2, the removeAbandoned property is split
into two different properties:  removeAbandonedOnBorrow (the old
behavior) and removeAbandonedOnMaintenance.  The second one makes
abandoned connection removal run on pool maintenance (so will not
have to wait until a borrow is attempted).

Phil
>
> Thanks,
> Shawn
>
> p.s. I sent an earlier draft of this message, but did so from the wrong
> email address.  If the moderators decide to allow that message through,
> then you may see an almost-duplicate of this message.
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Shawn Heisey]

On 3/21/2018 1:31 AM, Mark Thomas wrote:
>> and that we need to
>> change the factory on our pool definitions.
> I believe not.

Tomcat's documentation seems to disagree with this point. It
specifically says to use org.apache.tomcat.jdbc.pool.DataSourceFactory,
and doesn't list any other valid choices.  But we have
org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory in our
configuration.  I've found questions from people whose Tomcat
installations didn't even contain that class, where the answers said to
switch to the factory in the documentation.  Apparently deb-based
packages of Tomcat do not contain the latter class.

I found a historical document for 7.0.42 with Google and it also shows
that the factory should be set to the DataSourceFactory, not the
BasicDataSourceFactory that we have.

I do see "removeAbandoned" in the property constants in the 7.0 source
code for BasicDataSourceFactory.  I had thought that it wasn't there,
but I realized that I was looking at trunk code when I came to that
conclusion, and that BasicDataSourceFactory is in a dbcp2 package in
trunk.  So I'm not sure what to think, but I can say that the abandoned
connection handling does not appear to actually be working.  So either
my configuration is wrong, or the factory that we are using is ignoring
part of the config.

Thanks,
Shawn

p.s. I sent an earlier draft of this message, but did so from the wrong
email address.  If the moderators decide to allow that message through,
then you may see an almost-duplicate of this message.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Mark Thomas]

On 21/03/18 04:49, Shawn Heisey wrote:
> On 3/20/2018 9:49 PM, Phil Steitz wrote:
>> First, find out what version of tomcat you are running.  Then look
>> in the tomcat build file sources for the properties that define the
>> dbcp and pool versions being used.  In TC 7, I am pretty sure the
>> repackaged sources were always from release tags.  Ask again if you
>> have trouble locating the dbcp/pool versions once you know the TC
>> version.
> 
> Tomcat on the system I'm looking at is 7.0.42, bundled with Liferay 6.2.

Tomcat 7 uses DBCP 1.x (and always will).

>> In DBCP 1.x (what TC 7 used), abandoned connection tracking was in
>> the AbandonedObjectPool bundled with DBCP.  Tracking can be turned
>> on by configuration of BasicDataSource to remove abandoned
>> connections and to log them.  When connections are considered
>> abandoned and closed, the stack trace of the code that created them
>> is logged.  That requires that they actually go past the abandoned
>> connection timeout, though and get closed by the pool.
> 
> In the pool definitions (which are in tomcat's context.xml),
> removeAbandoned is true, and removeAbandonedTimeout is set to 30.  (this
> is really low!)  But this does not appear to actually be happening.  I
> see connections on the server (which look like they are from the
> configured pool) that have been idle for HOURS.
> 
> Here's a relevant definition, slightly redacted:
> 
>      factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
> driverClassName="com.mysql.jdbc.Driver" type="javax.sql.DataSource"
> maxActive="60" maxIdle="10" maxWait="3" removeAbandoned="true"
> removeAbandonedTimeout="30" username="REDACTED" password="REDACTED"
> testOnBorrow="true" validationQuery="select 1"
> url="jdbc:mysql://encore.REDACTED.com:3306/REDACTED?autoReconnect=truezeroDateTimeBehavior=round"
> />
> 
> The factory is different from the recommended value in the 7.0 docs
> (which specifically say 7.0.85, I've got 7.0.42).  Those docs say it
> should be org.apache.tomcat.jdbc.pool.DataSourceFactory.  I wonder if
> this means that it's ignoring some of the pool configuration.

org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory is the default
factory and the correct factory to use for Tomcat's re-packaged version
of DBCP.

For the record, the code is an exact copy of the DBCP code (at the point
the copy was updated). Tomcat doesn't make any local changes.

Another reason for the repackaging is to prevent conflicts if an
application includes its own copy of Commons DBCP.

org.apache.tomcat.jdbc.pool.DataSourceFactory is the factory to use for
Tomcat's JDBC pool implementation.

> In a surface review of our application DB code, I have encountered a
> common theme:  Connections are obtained, used, and closed, all within a
> try block.  It is my understanding that closes should actually be done
> in a finally block (with null checks), to be absolutely certain that a
> close cannot be skipped, regardless of any exceptions that might occur. 
> I suspect that this is the root of our troubles,

+1

> and that we need to
> change the factory on our pool definitions.

I believe not.

Mark

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Shawn Heisey]

On 3/20/2018 9:49 PM, Phil Steitz wrote:

First, find out what version of tomcat you are running.  Then look
in the tomcat build file sources for the properties that define the
dbcp and pool versions being used.  In TC 7, I am pretty sure the
repackaged sources were always from release tags.  Ask again if you
have trouble locating the dbcp/pool versions once you know the TC
version.


Tomcat on the system I'm looking at is 7.0.42, bundled with Liferay 6.2.


In DBCP 1.x (what TC 7 used), abandoned connection tracking was in
the AbandonedObjectPool bundled with DBCP.  Tracking can be turned
on by configuration of BasicDataSource to remove abandoned
connections and to log them.  When connections are considered
abandoned and closed, the stack trace of the code that created them
is logged.  That requires that they actually go past the abandoned
connection timeout, though and get closed by the pool.


In the pool definitions (which are in tomcat's context.xml), 
removeAbandoned is true, and removeAbandonedTimeout is set to 30.  (this 
is really low!)  But this does not appear to actually be happening.  I 
see connections on the server (which look like they are from the 
configured pool) that have been idle for HOURS.


Here's a relevant definition, slightly redacted:

    factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" 
driverClassName="com.mysql.jdbc.Driver" type="javax.sql.DataSource" 
maxActive="60" maxIdle="10" maxWait="3" removeAbandoned="true" 
removeAbandonedTimeout="30" username="REDACTED" password="REDACTED" 
testOnBorrow="true" validationQuery="select 1" 
url="jdbc:mysql://encore.REDACTED.com:3306/REDACTED?autoReconnect=truezeroDateTimeBehavior=round" 
/>


The factory is different from the recommended value in the 7.0 docs 
(which specifically say 7.0.85, I've got 7.0.42).  Those docs say it 
should be org.apache.tomcat.jdbc.pool.DataSourceFactory.  I wonder if 
this means that it's ignoring some of the pool configuration.


In a surface review of our application DB code, I have encountered a 
common theme:  Connections are obtained, used, and closed, all within a 
try block.  It is my understanding that closes should actually be done 
in a finally block (with null checks), to be absolutely certain that a 
close cannot be skipped, regardless of any exceptions that might occur.  
I suspect that this is the root of our troubles, and that we need to 
change the factory on our pool definitions.


Thank you to both people who have replied to this thread so far.

Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Phil Steitz]

On 3/20/18 7:21 PM, Shawn Heisey wrote:
> I've written before, trying to track down problems with our
> database server getting too many connections.
>
> Based on what I can see of how my programs (using dbcp2) are
> working, everything seems to be fine there.  I've added logging to
> tell me how many idle and active connections there are in the
> pool, and those numbers stay low.
>
> So now I need to track down what's happening in our webapps, most
> of which are Liferay-based, and all of which are running in
> Tomcat.  And I've learned that they're using the Tomcat
> implementation of dbcp for database access.  I think it's Tomcat
> version 7, but I will need to check to make sure.
>
> I've figured out how to log the number of active and idle
> connections, by casting the DataSource to the tomcat dbcp object
> actually in use.  Once I can get the developers to actually update
> a production system with that code, I will be able to see whether
> (as I suspect) the "active" count in the pool is staying
> abnormally high.  I'm betting that there's somewhere in the webapp
> code that a connection is retrieved from the pool, used for some
> work, and never closed.
>
> I have a main question, and then a semi-related but very different
> question.
>
> Main Question:  Does dbcp by chance record a stacktrace of the
> code that requests a connection from the pool?  I would like to
> poke my way through the active connections (entry point being the
> DataSource implementation), and ask them where in our code they
> were requested.  I have to do this in the Tomcat fork of dbcp, and
> I know I'm not on a Tomcat mailing list, but I'm hoping that
> whatever you can tell me will apply to that version too.
First, find out what version of tomcat you are running.  Then look
in the tomcat build file sources for the properties that define the
dbcp and pool versions being used.  In TC 7, I am pretty sure the
repackaged sources were always from release tags.  Ask again if you
have trouble locating the dbcp/pool versions once you know the TC
version.

In DBCP 1.x (what TC 7 used), abandoned connection tracking was in
the AbandonedObjectPool bundled with DBCP.  Tracking can be turned
on by configuration of BasicDataSource to remove abandoned
connections and to log them.  When connections are considered
abandoned and closed, the stack trace of the code that created them
is logged.  That requires that they actually go past the abandoned
connection timeout, though and get closed by the pool.

> If I can get a stacktrace of where each connection was requested,
> I can pinpoint problematic code a lot faster.  There is a LOT of
> code that uses the database, scattered across a lot of git
> repositories.  If I could grep the code easily to find them all, I
> would.
>
> Side question: Why has Tomcat maintained what looks like a fork of
> dbcp for such a long time period?  If they really believe their
> implementation has an advantage, it seems like everyone would
> benefit if they worked to get the upstream library to offer the
> same advantages.  Am I drifting into flamewar territory by even
> wondering about this?  I did find the tomcat documentation page
> about their connection pool.  It basically reads to me as "Commons
> DBCP is substandard and bloated.  These are the many ways that our
> implementation is better."

There are two different things going on here.  The first is the
repackaged DBCP sources that tomcat ships as the default connection
pool.  That is not really a fork - just repackaging.  In the early
days of TC8, DBCP was not releasing fast enough, so IIRC a few TC
releases shipped pre-release DBCP sources, but there was never
really any forking going on.  The second thing is the tomcat's
"jdbc-pool" module that is an alternative to DBCP.  The content on
the web page you reference is obsolete and probably should be
fixed.  It refers back to 1.x versions of DBCP that used 1.x
versions of pool.  Those were in fact slow and buggy.  The 2.x
versions of DBCP have comparable performance (slightly slower, but
not much) to jdbc-pool (mostly because pool 2.x is much faster).  
Depending on which version of TC 7 you are running, jdbc-pool for
that version might be materially faster than DBCP version shipped
with it.

Phil
>
> https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html
>
> I haven't compared DBCP with other pool implementations, but my
> work with DBCP has never run into any problems that weren't my own
> fault.  This mailing list has shown a high degree of patience with
> my dumb questions.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] troubleshooting pool activity (tomcat version)

[Matt Sicker]

On Tue, Mar 20, 2018 at 21:21, Shawn Heisey <apa...@elyograg.org> wrote:

> Main Question:  Does dbcp by chance record a stacktrace of the code that
> requests a connection from the pool?  I would like to poke my way
> through the active connections (entry point being the DataSource
> implementation), and ask them where in our code they were requested.


Yes, that’s a flag you set in the data source. See for example
BasicDataSource: abandoned usage tracking.

I
> have to do this in the Tomcat fork of dbcp, and I know I'm not on a
> Tomcat mailing list, but I'm hoping that whatever you can tell me will
> apply to that version too.  If I can get a stacktrace of where each
> connection was requested, I can pinpoint problematic code a lot faster.
> There is a LOT of code that uses the database, scattered across a lot of
> git repositories.  If I could grep the code easily to find them all, I
> would.


IIRC, DBCP came from Tomcat in the first place. And they keep it synced
upstream.


>
> Side question: Why has Tomcat maintained what looks like a fork of dbcp
> for such a long time period?  If they really believe their
> implementation has an advantage, it seems like everyone would benefit if
> they worked to get the upstream library to offer the same advantages.
> Am I drifting into flamewar territory by even wondering about this?  I
> did find the tomcat documentation page about their connection pool.  It
> basically reads to me as "Commons DBCP is substandard and bloated.
> These are the many ways that our implementation is better."
>
> https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html
>
> I haven't compared DBCP with other pool implementations, but my work
> with DBCP has never run into any problems that weren't my own fault.
> This mailing list has shown a high degree of patience with my dumb
> questions.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
> --
Matt Sicker <boa...@gmail.com>

[DBCP] troubleshooting pool activity (tomcat version)

[Shawn Heisey]

I've written before, trying to track down problems with our database 
server getting too many connections.


Based on what I can see of how my programs (using dbcp2) are working, 
everything seems to be fine there.  I've added logging to tell me how 
many idle and active connections there are in the pool, and those 
numbers stay low.


So now I need to track down what's happening in our webapps, most of 
which are Liferay-based, and all of which are running in Tomcat.  And 
I've learned that they're using the Tomcat implementation of dbcp for 
database access.  I think it's Tomcat version 7, but I will need to 
check to make sure.


I've figured out how to log the number of active and idle connections, 
by casting the DataSource to the tomcat dbcp object actually in use.  
Once I can get the developers to actually update a production system 
with that code, I will be able to see whether (as I suspect) the 
"active" count in the pool is staying abnormally high.  I'm betting that 
there's somewhere in the webapp code that a connection is retrieved from 
the pool, used for some work, and never closed.


I have a main question, and then a semi-related but very different question.

Main Question:  Does dbcp by chance record a stacktrace of the code that 
requests a connection from the pool?  I would like to poke my way 
through the active connections (entry point being the DataSource 
implementation), and ask them where in our code they were requested.  I 
have to do this in the Tomcat fork of dbcp, and I know I'm not on a 
Tomcat mailing list, but I'm hoping that whatever you can tell me will 
apply to that version too.  If I can get a stacktrace of where each 
connection was requested, I can pinpoint problematic code a lot faster.  
There is a LOT of code that uses the database, scattered across a lot of 
git repositories.  If I could grep the code easily to find them all, I 
would.


Side question: Why has Tomcat maintained what looks like a fork of dbcp 
for such a long time period?  If they really believe their 
implementation has an advantage, it seems like everyone would benefit if 
they worked to get the upstream library to offer the same advantages.  
Am I drifting into flamewar territory by even wondering about this?  I 
did find the tomcat documentation page about their connection pool.  It 
basically reads to me as "Commons DBCP is substandard and bloated.  
These are the many ways that our implementation is better."


https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html

I haven't compared DBCP with other pool implementations, but my work 
with DBCP has never run into any problems that weren't my own fault.  
This mailing list has shown a high degree of patience with my dumb 
questions.


Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] Connection pool not behaving as I expect

[Shawn Heisey]

On 3/1/2018 8:48 PM, Matt Sicker wrote:

Take a look inside commons-pool for the instrumentation (e.g., JMX). You
can also track usage on borrow and other leaks.

Also, Tomcat uses DBCP as it is.


I know I can get those numbers from the object pool, but at the point 
where I needed them, I don't actually know *which* DataSource is being 
used.  It could be one of two.  So I don't know which object pool to 
look at.


Interim solution before I switch to BasicDataSource:  Log info from BOTH 
pools.  I did this, and here's some info that gets logged on the dev 
server where I installed the change:


WARN  - 2018-03-01 21:59:00.313;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.314;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.315;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.316;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.318;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.319;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.320;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.321;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.322;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.323;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.324;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1
WARN  - 2018-03-01 21:59:00.325;   371; c; CP: main-active=0, 
main-idle=1, master-active=0, master-idle=1


This logging happens just before a connection is obtained from the 
pool.  The info logged is the same -- zero active, one or more idle.  
Except during program startup, when there are some lines where both are 
zero.  And once an hour, there is a background thread that does a query 
that takes nearly a minute to run, and while that's happening, I do see 
main-active=1.


I did just now think of one possibility that might explain why this 
program misbehaves when the problem happens, even if DBCP is working 
right.  Based on the logging I've enabled, and the fact that nobody has 
said "oh, we see that all the time, and the problem is probably X" ... I 
think DBCP probably is working right.



Basic info about my program: All reads are done via the "main" pool, 
which connects to a slave, unless connections there are not working, 
then reads switch to the "master" pool for the next 1000 connections.  
All writes are done via the "master" pool.


When the master server reaches its connection limit, a completely 
separate process that adds information to the monster table in the DB 
cannot work.  It's not Java-based, and doesn't have connection pooling 
available.


When there are no new docs in the monster table, my program doesn't have 
anything to do, so it doesn't need to make any changes to its control 
table -- it's not going to be using the master pool.  That probably 
results in the idle connection to the master server being evicted five 
minutes after the additions to the database stop.  Then because there's 
now a connection available on the server, the other system can suddenly 
add some documents.  So my program notices the new docs via its main 
pool, processes them, and then it would need to update its control table 
on the master server.  There's no idle connection because it got 
evicted, so it tries to make a new one, and we get an explosion.



I still do have the separate problem of why our app servers explode with 
"Too many connections" exceptions, when the DB pools there have dozens 
of active connections.  I didn't write that code.  Maybe their DB access 
(which is primarily through hibernate, a library I don't know much 
about) is not properly releasing connections back to the pool, so the 
pool does not think they're actually idle.  I will need to see what 
logging they can add.


Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] Connection pool not behaving as I expect

[Matt Sicker]

Take a look inside commons-pool for the instrumentation (e.g., JMX). You
can also track usage on borrow and other leaks.

Also, Tomcat uses DBCP as it is.

On 1 March 2018 at 21:46, Shawn Heisey <apa...@elyograg.org> wrote:

> On 3/1/2018 4:46 PM, Gary Gregory wrote:
>
>> I do not think this is a question I, or anyone here, can answer
>> generically. I can read between that lines that you must feel frustrated
>> and I certainly empathize with that. I think you might want to debug your
>> application and come up with some parameters for us to start helping you.
>> A
>> reproducible example is always best but I understand it might be hard to
>> provide in this particular case.
>>
>
> There is a lot of frustration.  Until today all of it was directed at our
> developers, for creating programs and configs that make way too many
> connections to the DB.
>
> But then today, I had that small eureka moment, thinking "wait a minute
> ... how can this even be happening at all, if the connection pool has
> connections that the DB server says are active and idle?"
>
> Reiterating something I said before: I know you can't help me with the
> pools that the Tomcat servers are creating for our webapps.  So I'll limit
> the rest of the discussion to my own program, which uses DBCP, and has the
> same problems.
>
> Please tell me what information you'd like me to provide. Anything that is
> in my power, I will get it to you.
>
> This is how I set up DBCP in my code:
>
>   /*
>* Create a datasource (connection pool) for the master database server.
>*/
>   ConnectionFactory cfMaster = new DriverManagerConnectionFactory(masterUrl,
> dbUser, dbPass);
>   PoolableConnectionFactory pcfMaster = new 
> PoolableConnectionFactory(cfMaster,
> null);
>   pcfMaster.setValidationQuery(validationQuery);
>   pcfMaster.setValidationQueryTimeout(Const.FIVE_SECONDS / 1000);
>   opMaster = new GenericObjectPool<>(pcfMaster);
>   opMaster.setMaxWaitMillis(Const.THIRTY_SECONDS);
>   opMaster.setMaxIdle(numShards);
>   opMaster.setMaxTotal(numShards * 5);
>   opMaster.setNumTestsPerEvictionRun(numShards * 5);
> opMaster.setTimeBetweenEvictionRunsMillis(Const.FIVE_SECONDS);
>   opMaster.setMinEvictableIdleTimeMillis(Const.ONE_MINUTE * 5);
>   opMaster.setTestOnCreate(true);
>   opMaster.setTestOnBorrow(true);
>   opMaster.setTestOnReturn(true);
>   opMaster.setTestWhileIdle(true);
>   pcfMaster.setPool(opMaster);
>   dsMaster = new PoolingDataSource<>(opMaster);
>
> The JDBC driver we use is MySQL.  As of a few weeks ago, it was the newest
> stable version available, 5.1.something.  Also at that time, I was using
> the latest DBCP and POOL versions.  If any new versions have come out very
> recently, I probably don't have them yet.
>
> Typically the numShards value we're using is 6, to help with understanding
> the code above.
>
> Observations: When the MySQL server has reached its connection limit, at
> least one of the idle connections is from this program using DBCP.  But
> when the program attempts to use the DB, it gets the "Too many connections"
> error response -- which means that it must be opening a brand new
> connection, despite the fact that there SHOULD be at least one that is
> ready and sitting in the pool.
>
> The code that uses the DB is basic JDBC code.  It calls getConnection() on
> the dataSource, verifies that the connection is valid, creates a statement,
> executes it, and if it was a query, processes the resultset.  Then it
> closes any resultset, closes the statement, and closes the connection.  As
> I understand it, that close should return the connection to the pool, still
> open, and ready for re-use.  This all happens within a single thread.  I
> went through this code pretty closely for another issue on this mailing
> list.  It's possible that I missed something, but it looks very clean.
>
> I was going to add some debug logging to my code, but I can't see any way
> with PoolingDataSource to get the number of active and idle connections,
> just to make SURE that the pool really has what I think it does.
>
> I have a code change ready to switch everything to BasicDataSource and add
> the debug logging.  It's generally less verbose code, and looks to be just
> as configurable as PoolingDataSource.  Would that change be a good idea?
>
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>


-- 
Matt Sicker <boa...@gmail.com>

Re: [DBCP] Connection pool not behaving as I expect

[Shawn Heisey]

On 3/1/2018 4:46 PM, Gary Gregory wrote:

I do not think this is a question I, or anyone here, can answer
generically. I can read between that lines that you must feel frustrated
and I certainly empathize with that. I think you might want to debug your
application and come up with some parameters for us to start helping you. A
reproducible example is always best but I understand it might be hard to
provide in this particular case.


There is a lot of frustration.  Until today all of it was directed at 
our developers, for creating programs and configs that make way too many 
connections to the DB.


But then today, I had that small eureka moment, thinking "wait a minute 
... how can this even be happening at all, if the connection pool has 
connections that the DB server says are active and idle?"


Reiterating something I said before: I know you can't help me with the 
pools that the Tomcat servers are creating for our webapps.  So I'll 
limit the rest of the discussion to my own program, which uses DBCP, and 
has the same problems.


Please tell me what information you'd like me to provide. Anything that 
is in my power, I will get it to you.


This is how I set up DBCP in my code:

  /*
   * Create a datasource (connection pool) for the master database server.
   */
  ConnectionFactory cfMaster = new 
DriverManagerConnectionFactory(masterUrl, dbUser, dbPass);
  PoolableConnectionFactory pcfMaster = new 
PoolableConnectionFactory(cfMaster, null);

  pcfMaster.setValidationQuery(validationQuery);
  pcfMaster.setValidationQueryTimeout(Const.FIVE_SECONDS / 1000);
  opMaster = new GenericObjectPool<>(pcfMaster);
  opMaster.setMaxWaitMillis(Const.THIRTY_SECONDS);
  opMaster.setMaxIdle(numShards);
  opMaster.setMaxTotal(numShards * 5);
  opMaster.setNumTestsPerEvictionRun(numShards * 5);
opMaster.setTimeBetweenEvictionRunsMillis(Const.FIVE_SECONDS);
  opMaster.setMinEvictableIdleTimeMillis(Const.ONE_MINUTE * 5);
  opMaster.setTestOnCreate(true);
  opMaster.setTestOnBorrow(true);
  opMaster.setTestOnReturn(true);
  opMaster.setTestWhileIdle(true);
  pcfMaster.setPool(opMaster);
  dsMaster = new PoolingDataSource<>(opMaster);

The JDBC driver we use is MySQL.  As of a few weeks ago, it was the 
newest stable version available, 5.1.something.  Also at that time, I 
was using the latest DBCP and POOL versions.  If any new versions have 
come out very recently, I probably don't have them yet.


Typically the numShards value we're using is 6, to help with 
understanding the code above.


Observations: When the MySQL server has reached its connection limit, at 
least one of the idle connections is from this program using DBCP.  But 
when the program attempts to use the DB, it gets the "Too many 
connections" error response -- which means that it must be opening a 
brand new connection, despite the fact that there SHOULD be at least one 
that is ready and sitting in the pool.


The code that uses the DB is basic JDBC code.  It calls getConnection() 
on the dataSource, verifies that the connection is valid, creates a 
statement, executes it, and if it was a query, processes the resultset.  
Then it closes any resultset, closes the statement, and closes the 
connection.  As I understand it, that close should return the connection 
to the pool, still open, and ready for re-use.  This all happens within 
a single thread.  I went through this code pretty closely for another 
issue on this mailing list.  It's possible that I missed something, but 
it looks very clean.


I was going to add some debug logging to my code, but I can't see any 
way with PoolingDataSource to get the number of active and idle 
connections, just to make SURE that the pool really has what I think it 
does.


I have a code change ready to switch everything to BasicDataSource and 
add the debug logging.  It's generally less verbose code, and looks to 
be just as configurable as PoolingDataSource.  Would that change be a 
good idea?


Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] Connection pool not behaving as I expect

[Phil Steitz]

> On Mar 1, 2018, at 3:33 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> 
> We have been having some problems lately where our MySQL server hits the
> max connection limit (600) and then everything breaks.  When I look into
> the problem, I find that our application servers have each made nearly a
> hundred connections to the DB and haven't closed any of them for hours.
> 
> I'm also using connection pooling in my programs, with the latest DBCP
> version.  Those servers don't open nearly as many connections, and have
> idle eviction to keep the connection count down.  But when the limit is
> reached, these programs suddenly stop working too.
> 
> Investigating these problems, I manage to get connected and kill off the
> surplus of idle connections, and everything starts working.
> 
> Today, a couple of days after the last incident, I realized that we
> should *NOT* be having these problems -- because we're using connection
> pooling.  The application has open and idle connections to the DB server
> ... so why is trying to open MORE connections (and obviously failing)
> instead of using one of the perfectly good connections that's already
> sitting there, unused?
> 
> I'm writing here specifically for DBCP on my programs, so I know you
> guys probably can't help with Tomcat's connection pooling ... but for
> either case my question stands:  Why isn't connection pooling doing its job?

Best to start by posting your pool config.  One thing to bear in mind is that 
“idle” from The dB perspective does not mean the same thing as idle from the 
pool’s perspective.  In addition to genuinely abandoned connections, another 
way that applications can hog dB connections is to check them out and hold them 
for a long time while not using them.  On the dB engine side these will show as 
idle, but as they are checked out to clients they are not available in the 
pool.  When you are having the problem, what does dB one report as numidle?

Phil
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [DBCP] Connection pool not behaving as I expect

[Gary Gregory]

On Thu, Mar 1, 2018 at 3:33 PM, Shawn Heisey  wrote:

> We have been having some problems lately where our MySQL server hits the
> max connection limit (600) and then everything breaks.  When I look into
> the problem, I find that our application servers have each made nearly a
> hundred connections to the DB and haven't closed any of them for hours.
>
> I'm also using connection pooling in my programs, with the latest DBCP
> version.  Those servers don't open nearly as many connections, and have
> idle eviction to keep the connection count down.  But when the limit is
> reached, these programs suddenly stop working too.
>
> Investigating these problems, I manage to get connected and kill off the
> surplus of idle connections, and everything starts working.
>
> Today, a couple of days after the last incident, I realized that we
> should *NOT* be having these problems -- because we're using connection
> pooling.  The application has open and idle connections to the DB server
> ... so why is trying to open MORE connections (and obviously failing)
> instead of using one of the perfectly good connections that's already
> sitting there, unused?
>
> I'm writing here specifically for DBCP on my programs, so I know you
> guys probably can't help with Tomcat's connection pooling ... but for
> either case my question stands:  Why isn't connection pooling doing its
> job?
>

I do not think this is a question I, or anyone here, can answer
generically. I can read between that lines that you must feel frustrated
and I certainly empathize with that. I think you might want to debug your
application and come up with some parameters for us to start helping you. A
reproducible example is always best but I understand it might be hard to
provide in this particular case.

Gary


> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

[DBCP] Connection pool not behaving as I expect

[Shawn Heisey]

We have been having some problems lately where our MySQL server hits the
max connection limit (600) and then everything breaks.  When I look into
the problem, I find that our application servers have each made nearly a
hundred connections to the DB and haven't closed any of them for hours.

I'm also using connection pooling in my programs, with the latest DBCP
version.  Those servers don't open nearly as many connections, and have
idle eviction to keep the connection count down.  But when the limit is
reached, these programs suddenly stop working too.

Investigating these problems, I manage to get connected and kill off the
surplus of idle connections, and everything starts working.

Today, a couple of days after the last incident, I realized that we
should *NOT* be having these problems -- because we're using connection
pooling.  The application has open and idle connections to the DB server
... so why is trying to open MORE connections (and obviously failing)
instead of using one of the perfectly good connections that's already
sitting there, unused?

I'm writing here specifically for DBCP on my programs, so I know you
guys probably can't help with Tomcat's connection pooling ... but for
either case my question stands:  Why isn't connection pooling doing its job?

Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [POOL] EvictionTimer daemon thread

[Gary Gregory]

On Wed, Jan 31, 2018 at 1:49 AM, Mark Thomas <ma...@apache.org> wrote:

> On 31/01/18 08:15, Bruno P. Kinoshita wrote:
> > Not sure if it was intentional.
> >
> > But here's the reason: https://github.com/apache/commons-pool/commit/
> 4a20cdca923bd342360f821d7020538e985d9ec2#diff-
> 38e254894b87bdf9a1758778c7ffd50fL167
> >
> > Instead of a `new Timer("", /* isDaemon */ true)`, now we have an
> implementation of `ThreadFactory` that when it creates new `Thread`s, it
> doesn't set the `setDaemon(true)`. So it just creates a thread with default
> behaviour of daemon set to false.
> >
> > As the previous behaviour was to have the threads as daemon, and there
> doesn't seem to have any arguments for dropping it, we could raise a new
> issue, with a patch, and ping Mark to see what he thinks?
>
> There is a typo in the commit message. The issue is POOL-315. It looks
> like I had finger trouble that day. I've spotted another typo in the
> changelog which I have now fixed.
>
> I don't recall any discussion of whether or not the threads should be
> daemon threads.
>
> Starting with a clean slate, I'd turn this around. What is the argument
> that the threads should be daemon threads?
>
> If the pool is correctly shutdown it should not matter as the evictor
> thread will be stopped at shutdown.
>

Are we sure that our shutdown logic always cleans up the thread-pool no
matter what?

Gary


>
> The only reason I can see for changing back to using a daemon thread is
> that it used to be a daemon thread and that allowed pools to be used
> without shutting them down cleanly.
>
> Overall, I guess I am neutral on changing it.
>
> Mark
>
>
> >
> > Cheers
> > Bruno
> >
> > (ps: the threads have a typo in their names, but it has been fixed in
> the master branch already)
> >
> >
> > ____
> > From: "Wegrzyn, Jakub" <jakub.wegr...@sabre.com>
> > To: Commons Users List <user@commons.apache.org>
> > Sent: Wednesday, 31 January 2018 8:54 PM
> > Subject: RE: [POOL] EvictionTimer daemon thread
> >
> >
> >
> > I couldn’t find it either.
> > Pool-351 was a commit message.
> > https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=commit;h=
> 4a20cdca923bd342360f821d7020538e985d9ec2
> >
> > Jakub
> >
> >
> > -Original Message-
> > From: Gary Gregory [mailto:garydgreg...@gmail.com]
> > Sent: Wednesday, January 31, 2018 8:28 AM
> > To: Commons Users List <user@commons.apache.org>
> > Subject: Re: [POOL] EvictionTimer daemon thread
> >
> > I cannot find a POOL-351 issue. Can you double check please?
> >
> > Gary
> >
> > On Jan 31, 2018 00:15, "Wegrzyn, Jakub" <jakub.wegr...@sabre.com> wrote:
> >
> >> Hi,
> >>
> >> We want to upgrade dbcp2 from version 2.1.1 to version 2.2.0. It
> >> requires upgrading commons-pool2 from version 2.4.2 to 2.5.0. However,
> >> during the upgrade we encountered a problem.
> >> It seems that commons-pool2 Evictor thread has been changed from
> >> daemon to non-daemon thread (Issue POOL-351, commit:
> >> 4a20cdca923bd342360f821d702053 8e985d9ec2).
> >>
> >> We cannot find any documentation describing the reason or the change
> >> itself. Can you provide more insight why that was changed and add it
> >> to the changes-report.
> >>
> >> Best regards,
> >> Jakub
> >>
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [POOL] EvictionTimer daemon thread

[Mark Thomas]

On 31/01/18 08:15, Bruno P. Kinoshita wrote:
> Not sure if it was intentional.
> 
> But here's the reason: 
> https://github.com/apache/commons-pool/commit/4a20cdca923bd342360f821d7020538e985d9ec2#diff-38e254894b87bdf9a1758778c7ffd50fL167
> 
> Instead of a `new Timer("", /* isDaemon */ true)`, now we have an 
> implementation of `ThreadFactory` that when it creates new `Thread`s, it 
> doesn't set the `setDaemon(true)`. So it just creates a thread with default 
> behaviour of daemon set to false.
> 
> As the previous behaviour was to have the threads as daemon, and there 
> doesn't seem to have any arguments for dropping it, we could raise a new 
> issue, with a patch, and ping Mark to see what he thinks?

There is a typo in the commit message. The issue is POOL-315. It looks
like I had finger trouble that day. I've spotted another typo in the
changelog which I have now fixed.

I don't recall any discussion of whether or not the threads should be
daemon threads.

Starting with a clean slate, I'd turn this around. What is the argument
that the threads should be daemon threads?

If the pool is correctly shutdown it should not matter as the evictor
thread will be stopped at shutdown.

The only reason I can see for changing back to using a daemon thread is
that it used to be a daemon thread and that allowed pools to be used
without shutting them down cleanly.

Overall, I guess I am neutral on changing it.

Mark


> 
> Cheers
> Bruno
> 
> (ps: the threads have a typo in their names, but it has been fixed in the 
> master branch already)
> 
> 
> 
> From: "Wegrzyn, Jakub" <jakub.wegr...@sabre.com>
> To: Commons Users List <user@commons.apache.org> 
> Sent: Wednesday, 31 January 2018 8:54 PM
> Subject: RE: [POOL] EvictionTimer daemon thread
> 
> 
> 
> I couldn’t find it either.
> Pool-351 was a commit message. 
> https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=commit;h=4a20cdca923bd342360f821d7020538e985d9ec2
> 
> Jakub 
> 
> 
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com] 
> Sent: Wednesday, January 31, 2018 8:28 AM
> To: Commons Users List <user@commons.apache.org>
> Subject: Re: [POOL] EvictionTimer daemon thread
> 
> I cannot find a POOL-351 issue. Can you double check please?
> 
> Gary
> 
> On Jan 31, 2018 00:15, "Wegrzyn, Jakub" <jakub.wegr...@sabre.com> wrote:
> 
>> Hi,
>>
>> We want to upgrade dbcp2 from version 2.1.1 to version 2.2.0. It 
>> requires upgrading commons-pool2 from version 2.4.2 to 2.5.0. However, 
>> during the upgrade we encountered a problem.
>> It seems that commons-pool2 Evictor thread has been changed from 
>> daemon to non-daemon thread (Issue POOL-351, commit: 
>> 4a20cdca923bd342360f821d702053 8e985d9ec2).
>>
>> We cannot find any documentation describing the reason or the change 
>> itself. Can you provide more insight why that was changed and add it 
>> to the changes-report.
>>
>> Best regards,
>> Jakub
>>
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [POOL] EvictionTimer daemon thread

[Bruno P. Kinoshita]

Not sure if it was intentional.

But here's the reason: 
https://github.com/apache/commons-pool/commit/4a20cdca923bd342360f821d7020538e985d9ec2#diff-38e254894b87bdf9a1758778c7ffd50fL167

Instead of a `new Timer("", /* isDaemon */ true)`, now we have an 
implementation of `ThreadFactory` that when it creates new `Thread`s, it 
doesn't set the `setDaemon(true)`. So it just creates a thread with default 
behaviour of daemon set to false.

As the previous behaviour was to have the threads as daemon, and there doesn't 
seem to have any arguments for dropping it, we could raise a new issue, with a 
patch, and ping Mark to see what he thinks?

Cheers
Bruno

(ps: the threads have a typo in their names, but it has been fixed in the 
master branch already)



From: "Wegrzyn, Jakub" <jakub.wegr...@sabre.com>
To: Commons Users List <user@commons.apache.org> 
Sent: Wednesday, 31 January 2018 8:54 PM
Subject: RE: [POOL] EvictionTimer daemon thread



I couldn’t find it either.
Pool-351 was a commit message. 
https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=commit;h=4a20cdca923bd342360f821d7020538e985d9ec2

Jakub 


-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Wednesday, January 31, 2018 8:28 AM
To: Commons Users List <user@commons.apache.org>
Subject: Re: [POOL] EvictionTimer daemon thread

I cannot find a POOL-351 issue. Can you double check please?

Gary

On Jan 31, 2018 00:15, "Wegrzyn, Jakub" <jakub.wegr...@sabre.com> wrote:

> Hi,
>
> We want to upgrade dbcp2 from version 2.1.1 to version 2.2.0. It 
> requires upgrading commons-pool2 from version 2.4.2 to 2.5.0. However, 
> during the upgrade we encountered a problem.
> It seems that commons-pool2 Evictor thread has been changed from 
> daemon to non-daemon thread (Issue POOL-351, commit: 
> 4a20cdca923bd342360f821d702053 8e985d9ec2).
>
> We cannot find any documentation describing the reason or the change 
> itself. Can you provide more insight why that was changed and add it 
> to the changes-report.
>
> Best regards,
> Jakub
>
B�CB��[��X��ܚX�KK[XZ[�\�\�][��X��ܚX�P��[[ۜ˘\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[�\�\�Z[��[[ۜ˘\X�K�ܙ�B�

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

RE: [POOL] EvictionTimer daemon thread

[Wegrzyn, Jakub]

I couldn’t find it either.
Pool-351 was a commit message. 
https://git-wip-us.apache.org/repos/asf?p=commons-pool.git;a=commit;h=4a20cdca923bd342360f821d7020538e985d9ec2

Jakub 

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Wednesday, January 31, 2018 8:28 AM
To: Commons Users List <user@commons.apache.org>
Subject: Re: [POOL] EvictionTimer daemon thread

I cannot find a POOL-351 issue. Can you double check please?

Gary

On Jan 31, 2018 00:15, "Wegrzyn, Jakub" <jakub.wegr...@sabre.com> wrote:

> Hi,
>
> We want to upgrade dbcp2 from version 2.1.1 to version 2.2.0. It 
> requires upgrading commons-pool2 from version 2.4.2 to 2.5.0. However, 
> during the upgrade we encountered a problem.
> It seems that commons-pool2 Evictor thread has been changed from 
> daemon to non-daemon thread (Issue POOL-351, commit: 
> 4a20cdca923bd342360f821d702053 8e985d9ec2).
>
> We cannot find any documentation describing the reason or the change 
> itself. Can you provide more insight why that was changed and add it 
> to the changes-report.
>
> Best regards,
> Jakub
>

Re: [POOL] EvictionTimer daemon thread

[Gary Gregory]

I cannot find a POOL-351 issue. Can you double check please?

Gary

On Jan 31, 2018 00:15, "Wegrzyn, Jakub" <jakub.wegr...@sabre.com> wrote:

> Hi,
>
> We want to upgrade dbcp2 from version 2.1.1 to version 2.2.0. It requires
> upgrading commons-pool2 from version 2.4.2 to 2.5.0. However, during the
> upgrade we encountered a problem.
> It seems that commons-pool2 Evictor thread has been changed from daemon to
> non-daemon thread (Issue POOL-351, commit: 4a20cdca923bd342360f821d702053
> 8e985d9ec2).
>
> We cannot find any documentation describing the reason or the change
> itself. Can you provide more insight why that was changed and add it to the
> changes-report.
>
> Best regards,
> Jakub
>

[POOL] EvictionTimer daemon thread

[Wegrzyn, Jakub]

Hi,

We want to upgrade dbcp2 from version 2.1.1 to version 2.2.0. It requires 
upgrading commons-pool2 from version 2.4.2 to 2.5.0. However, during the 
upgrade we encountered a problem.
It seems that commons-pool2 Evictor thread has been changed from daemon to 
non-daemon thread (Issue POOL-351, commit: 
4a20cdca923bd342360f821d7020538e985d9ec2).

We cannot find any documentation describing the reason or the change itself. 
Can you provide more insight why that was changed and add it to the 
changes-report.

Best regards,
Jakub

[ANNOUCEMENT] Apache Commons Pool 2.5.0

[Gary Gregory]

The Apache Commons Pool team is pleased to announce the release of Apache
Commons Pool 2.5.0.

Apache Commons Pool provides an object-pooling API and a number of object
pool implementations.
Version 2 contains a completely re-written pooling implementation compared
to the 1.x series.
In addition to performance and scalability improvements, version 2 includes
robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.

No client code changes are required to migrate from versions 2.4.x to
version 2.5.0.
Users of version 1.x should consult the migration guide on the Commons Pool
web site.

NOTE: The MBean interfaces (DefaultPooledObjectInfoMBean,
GenericKeyedObjectPoolMXBean
  and GenericKeyedObjectPoolMXBean) exist only to define the attributes
and methods
  that will be made available via JMX. They must not be implemented by
clients as
  they are subject to change between major, minor and patch version
releases of
  Commons Pool. Clients that implement any of these interfaces may not,
therefore,
  be able to upgrade to a new minor or patch release without requiring
code
  changes.

Changes in version 2.5.0 include:

New features:
o POOL-332:  ObjectPool and KeyedObject pool should extend Closeable.
o POOL-335:  Make abandoned logging stack trace requirements configurable.
This also reverts
 the default behavior introduced by POOL-320.


Changes:
o POOL-331:  Update from Java 6 to 7.
o POOL-333:  Update optional dependency asm-util from 5.2 to 6.0.
o POOL-334:  org.apache.commons.pool2.impl.ThrowableCallStack.Snapshot is
missing serialVersionUID.


For complete information on Apache Commons Pool, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons Pool
website:

http://commons.apache.org/proper/commons-pool/

Enjoy!
Gary Gregory, on behalf of the Apache Commons Team

Re: [pool] Any release plan for 2.4.3?

[Gary Gregory]

Apache Commons Pool 2.4.3 is in the release process. Distributions are
propagating to mirrors...

Gary

On Tue, May 31, 2016 at 4:33 PM, Jungtaek Lim <kabh...@gmail.com> wrote:

> Hi, I'm Jungtaek Lim, collaborator of Jedis (Java Redis Client).
>
> Jedis uses Commons Pool 2.x but stucks on POOL-303
> <https://issues.apache.org/jira/browse/POOL-303>.
> It seems to be going to be released to 2.4.3, but 2.4.2 is released at Aug.
> 2015 which is 10 months ago.
>
> So I'd like to hear about news for new release. Please let me know if we
> have, or please have a release plan if we don't have any.
>
> Thanks!
> Jungtaek Lim (HeartSaVioR)
>

Re: [pool] preparePool that only registers key, doesn't create new object

[Mark Thomas]

On 06/02/17 10:55, Mark Thomas wrote:

On 05/02/17 22:21, Gary Gregory wrote:

Anyone care to opine?


I think there is a bug in ensureMinIdle. If the objectDeque is null, it
needs to obtain a reference to the objectDeque once created in the for
loop. Otherwise the call from preparePool will always create
minIdlePerKey objects regardless of any objects created by the evictor.


Fixed in r1782329 for 2.4.3 onwards.

Mark




Mark



G

On Fri, Jan 20, 2017 at 7:38 AM, Martin Klepsch <
martinklep...@googlemail.com> wrote:


Hey,

With a KeyedObjectPool I can use `setMinIdlePerKey` &  `preparePool` to
"bootstrap" an object pool. Now `preparePool` creates new objects
synchronously and the evictor thread doesn't seem to ensure min idle
objects if there are none yet (since it can't know the keys I guess).

Because of that I run into the situation that the evictor thread creates
objects for keys that are currently being created by `preparePool`. It's
not an absolute deal breaker but it would be nice to be able to register
keys without synchronously creating the minimum idle objects. Instead
I'd
like to wait for the evictor thread to pick up newly registered keys and
create the required objects for it.

Unfortunately `register` is private and I don't see another way to
trigger
key-registering. (Calling `preparePool` with `minIdlePerKey` set to 0
will
short circuit and not register the key).

Any suggestions welcome!

Cheers :)








-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[pool] preparePool that only registers key, doesn't create new object

[Martin Klepsch]

Hey,

With a KeyedObjectPool I can use `setMinIdlePerKey` &  `preparePool` to
"bootstrap" an object pool. Now `preparePool` creates new objects
synchronously and the evictor thread doesn't seem to ensure min idle
objects if there are none yet (since it can't know the keys I guess).

Because of that I run into the situation that the evictor thread creates
objects for keys that are currently being created by `preparePool`. It's
not an absolute deal breaker but it would be nice to be able to register
keys without synchronously creating the minimum idle objects. Instead I'd
like to wait for the evictor thread to pick up newly registered keys and
create the required objects for it.

Unfortunately `register` is private and I don't see another way to trigger
key-registering. (Calling `preparePool` with `minIdlePerKey` set to 0 will
short circuit and not register the key).

Any suggestions welcome!

Cheers :)

Re: I need to close the connection, not return it back to the Connection Pool

[Phil Steitz]

On 12/22/16 7:22 PM, 王钦 wrote:
> Hi Shawn & Phil:
>
> Thank you for your help.
>
> The scenario I faced is like this:
>
> In the usual work time, there will be plenty of connections to
> the Impala Database. So I need a Connection Pool to manage them.
>
> When a query is executed for a long time and the client wants
> to cancel it manually, closing the connection for this query
> really is one solution (or maybe a poor solution.)

OK, so the best solution would be to find a way to kill or set a
timeout on the query, but I understand that may not be possible, so
you want to be more brutal and kill the connection.  The best here
would be to upgrade to DBCP 2.2 and use the invalidate method that
was added for this kind of use case.  Upgrading to DBCP2/Pool2 has
other benefits as well.  

Phil
>
> And thank you for your help again.
>
>
> Best Wishes
>
> Qin
>
>
>
> On 2016年12月23日 04:47, Phil Steitz wrote:
>> On 12/22/16 9:34 AM, Shawn Heisey wrote:
>>> On 12/22/2016 4:49 AM, 王钦 wrote:
>>>>  When I use DBCP-1.4 in my work, I need to close the
>>>> connection
>>>> which is generated by BasicDataSource. How can I do it? Close the
>>>> connection, while not returning it back to the Connection Pool.
>>> The PoolableConnection class (which I believe is the actual type of
>>> object you will receive from the data source) has a
>>> "reallyClose()" method.
>>>
>>> http://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/PoolableConnection.html#reallyClose()
>>>
>>>
>>> I'm no expert, but I think you might be able to cast the connection
>>> received from BasicDataSource to the Poolable variety.
>>>
>>> If you intend to "reallyClose()" every connection (rather than
>>> just some
>>> of them), I do have to wonder why you're using DBCP at all. 
>>> Obtaining
>>> connections from JDBC directly and closing them normally would
>>> accomplish the same thing without a code dependency and slightly
>>> less
>>> overhead.
>> I agree with your statement about defeating the purpose of the pool
>> if you do this every time.  If done only when the client knows the
>> connection is bad, the solution above will unfortunately leak pool
>> capacity (reallyClose doesn't inform the pool that the checked out
>> connection is never coming back).  A sort of ugly workaround for
>> that would be to enable abandoned connection cleanup, which would
>> eventually clean these up.
>>
>> What you need to do to do this cleanly is to get the underlying
>> GenericObjectPool to invalidate the PoolableConnection so its
>> accounting is correctly updated.  If you are willing to upgrade to
>> DBCP 2, BasicDataSource now has an invalidateConnection method that
>> handles this.  If not, the only way to do this without leaking
>> capacity is to do what the source for that method does, which
>> requires that you get a reference to the underlying object pool.
>> BasicDatasource does not expose that, so if you want to go this
>> route, you need to manually create the GOP and use a
>> PoolingDatasource.
>>
>> Phil
>>> Thanks,
>>> Shawn
>>>
>>>
>>> -
>>>
>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: user-h...@commons.apache.org
>>>
>>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>>
>
>
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: I need to close the connection, not return it back to the Connection Pool

[王钦]

Hi Shawn & Phil:

Thank you for your help.

The scenario I faced is like this:

In the usual work time, there will be plenty of connections to the 
Impala Database. So I need a Connection Pool to manage them.


When a query is executed for a long time and the client wants to 
cancel it manually, closing the connection for this query really is one 
solution (or maybe a poor solution.)


And thank you for your help again.


Best Wishes

Qin



On 2016年12月23日 04:47, Phil Steitz wrote:

On 12/22/16 9:34 AM, Shawn Heisey wrote:

On 12/22/2016 4:49 AM, 王钦 wrote:

 When I use DBCP-1.4 in my work, I need to close the connection
which is generated by BasicDataSource. How can I do it? Close the
connection, while not returning it back to the Connection Pool.

The PoolableConnection class (which I believe is the actual type of
object you will receive from the data source) has a "reallyClose()" method.

http://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/PoolableConnection.html#reallyClose()

I'm no expert, but I think you might be able to cast the connection
received from BasicDataSource to the Poolable variety.

If you intend to "reallyClose()" every connection (rather than just some
of them), I do have to wonder why you're using DBCP at all.  Obtaining
connections from JDBC directly and closing them normally would
accomplish the same thing without a code dependency and slightly less
overhead.

I agree with your statement about defeating the purpose of the pool
if you do this every time.  If done only when the client knows the
connection is bad, the solution above will unfortunately leak pool
capacity (reallyClose doesn't inform the pool that the checked out
connection is never coming back).  A sort of ugly workaround for
that would be to enable abandoned connection cleanup, which would
eventually clean these up.

What you need to do to do this cleanly is to get the underlying
GenericObjectPool to invalidate the PoolableConnection so its
accounting is correctly updated.  If you are willing to upgrade to
DBCP 2, BasicDataSource now has an invalidateConnection method that
handles this.  If not, the only way to do this without leaking
capacity is to do what the source for that method does, which
requires that you get a reference to the underlying object pool.
BasicDatasource does not expose that, so if you want to go this
route, you need to manually create the GOP and use a PoolingDatasource.

Phil

Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org







-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: I need to close the connection, not return it back to the Connection Pool

[Phil Steitz]

On 12/22/16 9:34 AM, Shawn Heisey wrote:
> On 12/22/2016 4:49 AM, 王钦 wrote:
>> When I use DBCP-1.4 in my work, I need to close the connection
>> which is generated by BasicDataSource. How can I do it? Close the
>> connection, while not returning it back to the Connection Pool. 
> The PoolableConnection class (which I believe is the actual type of
> object you will receive from the data source) has a "reallyClose()" method.
>
> http://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/PoolableConnection.html#reallyClose()
>
> I'm no expert, but I think you might be able to cast the connection
> received from BasicDataSource to the Poolable variety.
>
> If you intend to "reallyClose()" every connection (rather than just some
> of them), I do have to wonder why you're using DBCP at all.  Obtaining
> connections from JDBC directly and closing them normally would
> accomplish the same thing without a code dependency and slightly less
> overhead.

I agree with your statement about defeating the purpose of the pool
if you do this every time.  If done only when the client knows the
connection is bad, the solution above will unfortunately leak pool
capacity (reallyClose doesn't inform the pool that the checked out
connection is never coming back).  A sort of ugly workaround for
that would be to enable abandoned connection cleanup, which would
eventually clean these up. 

What you need to do to do this cleanly is to get the underlying
GenericObjectPool to invalidate the PoolableConnection so its
accounting is correctly updated.  If you are willing to upgrade to
DBCP 2, BasicDataSource now has an invalidateConnection method that
handles this.  If not, the only way to do this without leaking
capacity is to do what the source for that method does, which
requires that you get a reference to the underlying object pool. 
BasicDatasource does not expose that, so if you want to go this
route, you need to manually create the GOP and use a PoolingDatasource.

Phil
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: I need to close the connection, not return it back to the Connection Pool

[Shawn Heisey]

On 12/22/2016 4:49 AM, 王钦 wrote:
> When I use DBCP-1.4 in my work, I need to close the connection
> which is generated by BasicDataSource. How can I do it? Close the
> connection, while not returning it back to the Connection Pool. 

The PoolableConnection class (which I believe is the actual type of
object you will receive from the data source) has a "reallyClose()" method.

http://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/PoolableConnection.html#reallyClose()

I'm no expert, but I think you might be able to cast the connection
received from BasicDataSource to the Poolable variety.

If you intend to "reallyClose()" every connection (rather than just some
of them), I do have to wonder why you're using DBCP at all.  Obtaining
connections from JDBC directly and closing them normally would
accomplish the same thing without a code dependency and slightly less
overhead.

Thanks,
Shawn


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

I need to close the connection, not return it back to the Connection Pool

[王钦]

Hi All:
When I use DBCP-1.4 in my work, I need to close the connection 
which is generated by BasicDataSource. How can I do it? Close the 
connection, while not returning it back to the Connection Pool.


Thanks
Qin




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Can't get MySQL non-jta connection pool with Aries-2.4.0 and EL-2.6.2 working - Looking for (more) example(s).

[Timothy Ward]

Hi Erwin,

Sent from my iPhone

> On 25 Jul 2016, at 15:18, Erwin Hogeweg <erwin.hoge...@me.com> wrote:
> 
> Hi Tim,
> 
>> Have you considered using Aries Transaction Control?
> I definitely have, that was going to be my next step once I got this working. 
> I just can’t stand that I can’t figure this out. It is not rocket science 
> IMHO ;-)

Actually, it sort of is. The number of different services involved gets large 
very quickly! This is one of the reasons that the OSGi RFC for Transaction 
Control exists.

> 
>> It's typically much simpler to configure than the raw JDBC service, and it 
>> definitely gives you connection pooling (again, without extra moving parts).
> Thanks. I might bite the bullet and skip ahead to Aries Transactions. Would 
> have been nice to have a working platform as baseline.

Transaction Control still needs you to use JPA persistence bundles (i.e. 
Meta-Persistence) but it simplifies everything else a lot. You can configure 
your EntityManager with just a few config admin properties.

Tim

> 
> Erwin
> 
>> 
>> Best Regards,
>> 
>> Tim Ward
>> 
>> Sent from my iPhone
>> 
>> On 24 Jul 2016, at 21:51, Erwin Hogeweg 
>> <erwin.hoge...@me.com<mailto:erwin.hoge...@me.com>> wrote:
>> 
>> Hi,
>> 
>> Not sure if this is a question for these lists or for the EL list but I 
>> figure I start here. Feel free to redirect when you feel it doesn’t belong 
>> here.
>> 
>> I am trying to get a non-jta connection pool (internal connection pool) 
>> working with EL 2.6.2, Aries 2.4.0 (incl. EL adapter), dbcp2-2.1 and mySQL, 
>> but I must be missing something because I just can’t get it to work 
>> properly. Everything works just fine w/o a connection pool, so this is 
>> definitely the source of the misery.
>> 
>> Been struggling with this for a while now, and I am running out of ideas. I 
>> think I could use some sample code to point me in the right direction that 
>> doesn't use Blueprint? I found some of Christian’s examples, but I don’t 
>> think they are using connection pools.
>> 
>> Below a short summary of what I run into.
>> 
>> When I am using the ‘original’ MysqlDataSource...
>> 
>>   private DataSource createMySQLDataSource( Dictionary<String, String> 
>> dbConnProps ) {
>>   MysqlDataSource ds = new MysqlDataSource();
>>   ds.setUrl( dbConnProps.get( "jdbc_url" ) );
>>   ds.setUser( dbConnProps.get( "jdbc_user" ) );
>>   ds.setPassword( dbConnProps.get( "jdbc_password" ) );
>>   return ds;
>>   }
>> 
>> … everything kinda works normally. The DataSource, PersistenceProvider and 
>> EntityManagerFactory are all created and registered correctly;
>> 
>> g! services javax.sql.DataSource
>> {javax.sql.DataSource}={eclipselink.target-database=MySQL, 
>> osgi.jndi.service.name=jdbc/mynonjta, service.id=139, service.bundleid=104, 
>> service.scope=singleton}
>> "Registered by bundle:" 
>> com.my.project.persistence.mysqldatasource_4.0.0.SNAPSHOT [104]
>> 
>> g! services javax.persistence.EntityManagerFactory
>> {javax.persistence.EntityManagerFactory}={osgi.unit.version=4.0.0.SNAPSHOT, 
>> osgi.unit.name=my.pu, 
>> osgi.unit.provider=org.eclipse.persistence.jpa.PersistenceProvider, 
>> service.id=142, service.bundleid=98, service.scope=singleton}
>> "Registered by bundle:" com.my.project.model_4.0.0.SNAPSHOT [98]
>> 
>> The performance is horrible though as I don’t really seem to get a 
>> connection pool. The connection is closed after every query. On top of that 
>> I loose all network connections every few seconds with a:
>> 
>> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link 
>> failure
>> 
>> Which has me puzzled for a while now.
>> 
>> So my next attempt was to use the org.apache.commons.dbcp2.BasicDataSource:
>> 
>>  private DataSource createMySQLDataSource(  Dictionary<String, String> 
>> dbConnProps ) {
>> 
>>   BasicDataSource basicDataSource = new BasicDataSource();
>>   basicDataSource.setDriverClassName("com.mysql.jdbc.Driver");
>> ...
>>   return basicDataSource;
>>   }
>> 
>> This fails because the following exception:
>> 
>> [EL Severe]: 2016-07-24 
>> 14:41:55.872--java.lang.UnsupportedOperationException: Not supported by 
>> BasicDataSource
>> at 
>> org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1552)
>> 
>> Whic

Re: Can't get MySQL non-jta connection pool with Aries-2.4.0 and EL-2.6.2 working - Looking for (more) example(s).

[Erwin Hogeweg]

Hi Tim,

> Have you considered using Aries Transaction Control?
I definitely have, that was going to be my next step once I got this working. I 
just can’t stand that I can’t figure this out. It is not rocket science IMHO ;-)

> It's typically much simpler to configure than the raw JDBC service, and it 
> definitely gives you connection pooling (again, without extra moving parts).
Thanks. I might bite the bullet and skip ahead to Aries Transactions. Would 
have been nice to have a working platform as baseline.

Erwin

> 
> Best Regards,
> 
> Tim Ward
> 
> Sent from my iPhone
> 
> On 24 Jul 2016, at 21:51, Erwin Hogeweg 
> <erwin.hoge...@me.com<mailto:erwin.hoge...@me.com>> wrote:
> 
> Hi,
> 
> Not sure if this is a question for these lists or for the EL list but I 
> figure I start here. Feel free to redirect when you feel it doesn’t belong 
> here.
> 
> I am trying to get a non-jta connection pool (internal connection pool) 
> working with EL 2.6.2, Aries 2.4.0 (incl. EL adapter), dbcp2-2.1 and mySQL, 
> but I must be missing something because I just can’t get it to work properly. 
> Everything works just fine w/o a connection pool, so this is definitely the 
> source of the misery.
> 
> Been struggling with this for a while now, and I am running out of ideas. I 
> think I could use some sample code to point me in the right direction that 
> doesn't use Blueprint? I found some of Christian’s examples, but I don’t 
> think they are using connection pools.
> 
> Below a short summary of what I run into.
> 
> When I am using the ‘original’ MysqlDataSource...
> 
>private DataSource createMySQLDataSource( Dictionary<String, String> 
> dbConnProps ) {
>MysqlDataSource ds = new MysqlDataSource();
>ds.setUrl( dbConnProps.get( "jdbc_url" ) );
>ds.setUser( dbConnProps.get( "jdbc_user" ) );
>ds.setPassword( dbConnProps.get( "jdbc_password" ) );
>return ds;
>}
> 
> … everything kinda works normally. The DataSource, PersistenceProvider and 
> EntityManagerFactory are all created and registered correctly;
> 
> g! services javax.sql.DataSource
> {javax.sql.DataSource}={eclipselink.target-database=MySQL, 
> osgi.jndi.service.name=jdbc/mynonjta, service.id=139, service.bundleid=104, 
> service.scope=singleton}
>  "Registered by bundle:" 
> com.my.project.persistence.mysqldatasource_4.0.0.SNAPSHOT [104]
> 
> g! services javax.persistence.EntityManagerFactory
> {javax.persistence.EntityManagerFactory}={osgi.unit.version=4.0.0.SNAPSHOT, 
> osgi.unit.name=my.pu, 
> osgi.unit.provider=org.eclipse.persistence.jpa.PersistenceProvider, 
> service.id=142, service.bundleid=98, service.scope=singleton}
>  "Registered by bundle:" com.my.project.model_4.0.0.SNAPSHOT [98]
> 
> The performance is horrible though as I don’t really seem to get a connection 
> pool. The connection is closed after every query. On top of that I loose all 
> network connections every few seconds with a:
> 
> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link 
> failure
> 
> Which has me puzzled for a while now.
> 
> So my next attempt was to use the org.apache.commons.dbcp2.BasicDataSource:
> 
>   private DataSource createMySQLDataSource(  Dictionary<String, String> 
> dbConnProps ) {
> 
>BasicDataSource basicDataSource = new BasicDataSource();
>basicDataSource.setDriverClassName("com.mysql.jdbc.Driver");
> ...
>return basicDataSource;
>}
> 
> This fails because the following exception:
> 
> [EL Severe]: 2016-07-24 
> 14:41:55.872--java.lang.UnsupportedOperationException: Not supported by 
> BasicDataSource
> at 
> org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1552)
> 
> Which is this method:
> 
>@Override
>public Connection getConnection(String user, String pass) throws 
> SQLException {
>// This method isn't supported by the PoolingDataSource returned by
>// the createDataSource
>throw new UnsupportedOperationException("Not supported by 
> BasicDataSource");
>}
> 
> So I figured I create a version with a PoolingDataSource  (following the 
> PoolingDataSourceExample in svn):
> 
>ConnectionFactory connectionFactory = new 
> DriverManagerConnectionFactory(dbConnProps.get( "jdbc_url" ), "user", 
> "password");
>PoolableConnectionFactory poolableConnectionFactory = new 
> PoolableConnectionFactory(connectionFactory, null);
>ObjectPool connectionPool = new 
> GenericObjectPool<>(poolableConnectionFactory);
>poolableConn

Re: Can't get MySQL non-jta connection pool with Aries-2.4.0 and EL-2.6.2 working - Looking for (more) example(s).

[Timothy Ward]

Hi,

Have you considered using Aries Transaction Control? It's typically much 
simpler to configure than the raw JDBC service, and it definitely gives you 
connection pooling (again, without extra moving parts).

Best Regards,

Tim Ward

Sent from my iPhone

On 24 Jul 2016, at 21:51, Erwin Hogeweg 
<erwin.hoge...@me.com<mailto:erwin.hoge...@me.com>> wrote:

Hi,

Not sure if this is a question for these lists or for the EL list but I figure 
I start here. Feel free to redirect when you feel it doesn’t belong here.

I am trying to get a non-jta connection pool (internal connection pool) working 
with EL 2.6.2, Aries 2.4.0 (incl. EL adapter), dbcp2-2.1 and mySQL, but I must 
be missing something because I just can’t get it to work properly. Everything 
works just fine w/o a connection pool, so this is definitely the source of the 
misery.

Been struggling with this for a while now, and I am running out of ideas. I 
think I could use some sample code to point me in the right direction that 
doesn't use Blueprint? I found some of Christian’s examples, but I don’t think 
they are using connection pools.

Below a short summary of what I run into.

When I am using the ‘original’ MysqlDataSource...

private DataSource createMySQLDataSource( Dictionary<String, String> 
dbConnProps ) {
MysqlDataSource ds = new MysqlDataSource();
ds.setUrl( dbConnProps.get( "jdbc_url" ) );
ds.setUser( dbConnProps.get( "jdbc_user" ) );
ds.setPassword( dbConnProps.get( "jdbc_password" ) );
return ds;
}

… everything kinda works normally. The DataSource, PersistenceProvider and 
EntityManagerFactory are all created and registered correctly;

g! services javax.sql.DataSource
{javax.sql.DataSource}={eclipselink.target-database=MySQL, 
osgi.jndi.service.name=jdbc/mynonjta, service.id=139, service.bundleid=104, 
service.scope=singleton}
  "Registered by bundle:" 
com.my.project.persistence.mysqldatasource_4.0.0.SNAPSHOT [104]

g! services javax.persistence.EntityManagerFactory
{javax.persistence.EntityManagerFactory}={osgi.unit.version=4.0.0.SNAPSHOT, 
osgi.unit.name=my.pu, 
osgi.unit.provider=org.eclipse.persistence.jpa.PersistenceProvider, 
service.id=142, service.bundleid=98, service.scope=singleton}
  "Registered by bundle:" com.my.project.model_4.0.0.SNAPSHOT [98]

The performance is horrible though as I don’t really seem to get a connection 
pool. The connection is closed after every query. On top of that I loose all 
network connections every few seconds with a:

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link 
failure

Which has me puzzled for a while now.

So my next attempt was to use the org.apache.commons.dbcp2.BasicDataSource:

   private DataSource createMySQLDataSource(  Dictionary<String, String> 
dbConnProps ) {

BasicDataSource basicDataSource = new BasicDataSource();
basicDataSource.setDriverClassName("com.mysql.jdbc.Driver");
...
return basicDataSource;
}

This fails because the following exception:

[EL Severe]: 2016-07-24 14:41:55.872--java.lang.UnsupportedOperationException: 
Not supported by BasicDataSource
at 
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1552)

Which is this method:

@Override
public Connection getConnection(String user, String pass) throws 
SQLException {
// This method isn't supported by the PoolingDataSource returned by
// the createDataSource
throw new UnsupportedOperationException("Not supported by 
BasicDataSource");
}

So I figured I create a version with a PoolingDataSource  (following the 
PoolingDataSourceExample in svn):

ConnectionFactory connectionFactory = new 
DriverManagerConnectionFactory(dbConnProps.get( "jdbc_url" ), "user", 
"password");
PoolableConnectionFactory poolableConnectionFactory = new 
PoolableConnectionFactory(connectionFactory, null);
ObjectPool connectionPool = new 
GenericObjectPool<>(poolableConnectionFactory);
poolableConnectionFactory.setPool(connectionPool);
PoolingDataSource dataSource = new 
PoolingDataSource<>(connectionPool);
return dataSource;

But that still gives me an exception:

[EL Severe]: 2016-07-24 16:40:30.392--java.lang.UnsupportedOperationException
at 
org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:156)

So I am kinda lost now.

This is the relevant stuff from the persistence.xml file:

osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/mynonjta)











Although I only see one DataSource registered it somehow feels like there is 
some more stuff going on behind the (EL?) scenes that I don’t have a handle on 
yet.

BTW... I have also created an org.apache.aries.jpa.my.pu.cfg configuration 
file, but when I leave the DB properties out of the persistence.xm

Can't get MySQL non-jta connection pool with Aries-2.4.0 and EL-2.6.2 working - Looking for (more) example(s).

[Erwin Hogeweg]

Hi,

Not sure if this is a question for these lists or for the EL list but I figure 
I start here. Feel free to redirect when you feel it doesn’t belong here.

I am trying to get a non-jta connection pool (internal connection pool) working 
with EL 2.6.2, Aries 2.4.0 (incl. EL adapter), dbcp2-2.1 and mySQL, but I must 
be missing something because I just can’t get it to work properly. Everything 
works just fine w/o a connection pool, so this is definitely the source of the 
misery.

Been struggling with this for a while now, and I am running out of ideas. I 
think I could use some sample code to point me in the right direction that 
doesn't use Blueprint? I found some of Christian’s examples, but I don’t think 
they are using connection pools.

Below a short summary of what I run into.

When I am using the ‘original’ MysqlDataSource...

private DataSource createMySQLDataSource( Dictionary<String, String> 
dbConnProps ) {
MysqlDataSource ds = new MysqlDataSource();
ds.setUrl( dbConnProps.get( "jdbc_url" ) );
ds.setUser( dbConnProps.get( "jdbc_user" ) );
ds.setPassword( dbConnProps.get( "jdbc_password" ) );
return ds;
}

… everything kinda works normally. The DataSource, PersistenceProvider and 
EntityManagerFactory are all created and registered correctly;

g! services javax.sql.DataSource
{javax.sql.DataSource}={eclipselink.target-database=MySQL, 
osgi.jndi.service.name=jdbc/mynonjta, service.id=139, service.bundleid=104, 
service.scope=singleton}
  "Registered by bundle:" 
com.my.project.persistence.mysqldatasource_4.0.0.SNAPSHOT [104]

g! services javax.persistence.EntityManagerFactory
{javax.persistence.EntityManagerFactory}={osgi.unit.version=4.0.0.SNAPSHOT, 
osgi.unit.name=my.pu, 
osgi.unit.provider=org.eclipse.persistence.jpa.PersistenceProvider, 
service.id=142, service.bundleid=98, service.scope=singleton}
  "Registered by bundle:" com.my.project.model_4.0.0.SNAPSHOT [98]

The performance is horrible though as I don’t really seem to get a connection 
pool. The connection is closed after every query. On top of that I loose all 
network connections every few seconds with a:

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications 
link failure

Which has me puzzled for a while now.

So my next attempt was to use the org.apache.commons.dbcp2.BasicDataSource:

   private DataSource createMySQLDataSource(  Dictionary<String, String> 
dbConnProps ) {

BasicDataSource basicDataSource = new BasicDataSource();
basicDataSource.setDriverClassName("com.mysql.jdbc.Driver");
...
return basicDataSource;
}

This fails because the following exception:

[EL Severe]: 2016-07-24 14:41:55.872--java.lang.UnsupportedOperationException: 
Not supported by BasicDataSource
at 
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1552)

Which is this method:

@Override
public Connection getConnection(String user, String pass) throws 
SQLException {
// This method isn't supported by the PoolingDataSource returned by
// the createDataSource
throw new UnsupportedOperationException("Not supported by 
BasicDataSource");
}

So I figured I create a version with a PoolingDataSource  (following the 
PoolingDataSourceExample in svn): 

ConnectionFactory connectionFactory = new 
DriverManagerConnectionFactory(dbConnProps.get( "jdbc_url" ), "user", 
"password");
PoolableConnectionFactory poolableConnectionFactory = new 
PoolableConnectionFactory(connectionFactory, null);
ObjectPool connectionPool = new 
GenericObjectPool<>(poolableConnectionFactory);
poolableConnectionFactory.setPool(connectionPool);
PoolingDataSource dataSource = new 
PoolingDataSource<>(connectionPool);
return dataSource;

But that still gives me an exception:

[EL Severe]: 2016-07-24 16:40:30.392--java.lang.UnsupportedOperationException
at 
org.apache.commons.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:156)

So I am kinda lost now.

This is the relevant stuff from the persistence.xml file:


osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/mynonjta)


 
 



 
 
 


Although I only see one DataSource registered it somehow feels like there is 
some more stuff going on behind the (EL?) scenes that I don’t have a handle on 
yet.

BTW... I have also created an org.apache.aries.jpa.my.pu.cfg configuration 
file, but when I leave the DB properties out of the persistence.xml I get bunch 
of ClassNotFound exceptions, so that is suspicious.

BTW2… the examples link at the bottom of this page is broken: 
https://commons.apache.org/proper/commons-dbcp/ 
<https://commons.apache.org/proper/commons-dbcp/>


Regards,

Erwin

Re: [pool] Any release plan for 2.4.3?

[Gary Gregory]

I'm ok with pushing out a new release.

Any one else?

Gary
On May 31, 2016 3:33 PM, "Jungtaek Lim" <kabh...@gmail.com> wrote:

> Hi, I'm Jungtaek Lim, collaborator of Jedis (Java Redis Client).
>
> Jedis uses Commons Pool 2.x but stucks on POOL-303
> <https://issues.apache.org/jira/browse/POOL-303>.
> It seems to be going to be released to 2.4.3, but 2.4.2 is released at Aug.
> 2015 which is 10 months ago.
>
> So I'd like to hear about news for new release. Please let me know if we
> have, or please have a release plan if we don't have any.
>
> Thanks!
> Jungtaek Lim (HeartSaVioR)
>

[pool] Any release plan for 2.4.3?

[Jungtaek Lim]

Hi, I'm Jungtaek Lim, collaborator of Jedis (Java Redis Client).

Jedis uses Commons Pool 2.x but stucks on POOL-303
<https://issues.apache.org/jira/browse/POOL-303>.
It seems to be going to be released to 2.4.3, but 2.4.2 is released at Aug.
2015 which is 10 months ago.

So I'd like to hear about news for new release. Please let me know if we
have, or please have a release plan if we don't have any.

Thanks!
Jungtaek Lim (HeartSaVioR)

[POOL] Common pool eviction thread not working

[ruchi ahuja]

I am using apache commons pool 2 for object pooling.

The commons pool eviction thread is invoking the destroy method in test
environment. However I don't see it getting called in production.

How do I find the reason why it's not getting called?

[POOL] Common pool eviction thread not working

[ruchi ahuja]

I am using apache commons pool 2 for object pooling.

The commons pool eviction thread is invoking the destroy method in test
environment. However I don't see it getting called in production.

How do I find the reason why it's not getting called?

[pool] Reentrant Object Pool

[Adam Retter]

Hi,

I wonder if someone can help me or tell me if this is even possible
with Commons Pool 2.

I am looking for an Object pool that has reentrant like properties,
that is to say that each object in the pool would have an associated
reference count, and each time `borrowObject` is called from the same
thread, then the same object must be returned (and it's reference
count incremented). On returning the object, the object is only really
returned if it's reference count (which is decremented by the thread
for each returnObject call it makes) has reached zero .

It looked to me like it should not be too hard to add this either
implicitly to GenericObjectPool or even explicitly to
GenericKeyedObjectPool where the key is the Thread, and the pool size
for each key is set to 1.

I did try some local experiments, but it seems very hard to override
the methods of GenericKeyedObjectPool or GenericObjectPool without
being in the same package namespace :-/

Any thoughts? Has anyone done anything like this before?

Cheers Adam.

-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

RE: Maintain sub pools within Commons pool - is it possible

[Krishnakumar Parasuram]

Hi Gruss
Bernd

Though it is REST framework, when it actually connects to our Siebel Server 
which connection object are maintained in the connection pool, it is no more 
REST, it is based on TCPIP

Regards
Krishnakumar

-Original Message-
From: e...@zusammenkunft.net [mailto:e...@zusammenkunft.net] 
Sent: Friday, January 29, 2016 12:12 PM
To: d...@commons.apache.org
Subject: RE: Maintain sub pools within Commons pool - is it possible

(Ignore my mail, I missed the fact that the initial discussion was about REST 
clients not JdBC)

-- 
http://bernd.eckenfels.net

-Original Message-
From: e...@zusammenkunft.net
To: d...@commons.apache.org
Sent: Fr., 29 Jan. 2016 7:39
Subject: RE: Maintain sub pools within Commons pool - is it possible

Hello,

You can programmatically create and configure pools at runtime. (At least if 
you skip container infrastructures). You can even dynamically register the 
pools in JNDI. I dont think you need sub-pools for this. (Subpools would be 
more interesting for partitioning connections by transaction or session state).

The only problem I see would be to access the dynamic pools from JPA persitence 
declarations, however thats a problem which is nkt really solved with sub-pools 
either.

Gruss
Bernd

PS: i think this part of the discussion is better done on the user mailing list

-- 
http://bernd.eckenfels.net

-Original Message-
From: Krishnakumar Parasuram <parasuram.krishna.ku...@oracle.com>
To: d...@commons.apache.org
Sent: Do., 28 Jan. 2016 16:27
Subject: RE: FW: Maintain sub pools within Commons pool - is it possible

Hi Jochen,

 

Thanks for your message.  The difference between to two separate pools is that 
in our framework we don't know exactly how many no of separate pool we might 
require, it is not two, but can scale more than 10, 20 in production 
environment and I think to have so many pools and that to we have to create 
dynamically at runtime, not practical

 

If it was a sub pool, I can always create the sub pool based on demand at 
runtime.  Moreover we have few parameters for each sub pool to maintain a min 
and max connection objects, which parameters can be different for each sub pool 
and cannot be implemented while design as we do not know these value of these 
parameters at design time.

 

Please let me know if this answers your question else let know

 

Regards

Krishnakumar

 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[pool]Commons Pool for Golang

[Jole star]

I translate the Apache Commons Pool to Golang,  and open source  at
https://github.com/jolestar/go-commons-pool .

I've done most of the job， Does anyone interested in this？

-- 
Jolestar

[ANNOUNCEMENT] Apache Commons Pool 2.4.2 released

[Phil Steitz]

The Apache Commons Team is pleased to announce the release of Apache Commons 
Pool 2.4.2.

The Apache Commons Pool open source software library provides an object-pooling 
API and a number of object pool implementations.

No client code changes are required to migrate from any of the 2.x versions to 
2.4.2. Users of version 1.x should consult the migration guide on the Commons 
Pool web site.

Source and binary distributions are available for download from the Apache 
Commons download site:
http://commons.apache.org/pool/download_pool.cgi

When downloading, please verify signatures using the KEYS file available at the 
above location.

Full details of all the changes in 2.4.2 can be found in the changelog:
http://commons.apache.org/pool/changes-report.html

For complete information on Commons Pool, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Commons Pool website:
http://commons.apache.org/pool

Phil Steitz, on behalf of the Apache Commons community



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCEMENT] Apache Commons Pool 2.4.1 released

[Phil Steitz]

The Apache Commons Team is pleased to announce the release of Apache Commons 
Pool 2.4.1.

The Apache Commons Pool open source software library provides an object-pooling 
API and a number of object pool implementations.

No client code changes are required to migrate from any of the 2.x versions to 
2.4.1. Users of version 1.x should consult the migration guide on the Commons 
Pool web site.

Source and binary distributions are available for download from the Apache 
Commons download site:
http://commons.apache.org/proper/commons-pool/download_pool.cgi

When downloading, please verify signatures using the KEYS file available at the 
above location.

Full details of all the changes in 2.4.1 can be found in the changelog:
http://commons.apache.org/proper/commons-pool/changes-report.html

For complete information on Commons Pool, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Commons Pool website:
http://commons.apache.org/proper/commons-pool/

Phil Steitz, on behalf of the Apache Commons community



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: POOL - Question about different time out for borrow and add object

[Phil Steitz]

On 4/29/15 8:59 AM, vijay wrote:
 Hi ,

 I want to know if i can achieve this. Is there any way to specify time out
 for the addobject and borrow object methods?

 What i am really looking is when i start the pool i am prefilling it with
 add object for this i can wait for more time to geth the pool initialized.
 The backned system i have takes more time to crate connections

 But at the time of borrow i cannot have the client wait for long time if no
 idle connection is available and the factory make object method might take
 more time to  return object.

 So is there anyway i can tall factory method to wait for x time for add
 obkject and y time for borrow object calls

There is no timeout for addObject.  It is just a no-op if there is
no capacity to add to the pool when you call it.  If you are
prefilling at startup, that should not be a problem.  If you
actually *want* a timeout for the adds, then you need to implement
it in your factory itself.

Phil



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: POOL - Question about different time out for borrow and add object

[Phil Steitz]

On 4/29/15 12:55 PM, vijay wrote:
 Hi Phil..

 Thanks for response. i agree that add object is not problem as i am pre
 filling the pool and i can wait until the pool gets filled. But the real
 prob is with borrow object where i have to call the external system if
 there are no idle objects and the pool didn't reach the max size.

 In this case the pool will try to create new object by using factory make
 object method. The same method which add object also uses to add object to
 pool. I this case the borrow objeect call will get blocked until new
 connection is provided by external system (This could be some time more
 than 5 mins)

 The factory instance of the pool at this particular point has no
 information of whether the call has happened from borrow object or add
 object of pool to handle the time out based on add or borrow...This is
 where iam stuck ...

 can you help me how to implement it ..

Sorry, but pool can't really help with this use case.  The only
suggestion that I can make is to have your factory maintain state
itself - i.e., have it expose a property, say timeLimited and a
timeout value.  Have timeLimited false when you are preloading and
then set it to true and have the factory enforce the timeout. 
Another thing to note is that pool's borrowObject timeout limits the
amount of time that a thread waits for either an idle object or for
capacity to create one.  If a thread does get to create an object,
it will wait until the makeObject completes - i.e. (at least as of
2.3) the pool will not interrupt a thread waiting for a factory
method to complete.  That means that for your purpose, the
borrowObject timeout will not work either.

So basically the only solution that I can offer you is to have the
factory itself control the timeout.

Phil

 Thanks

 On Wed, Apr 29, 2015 at 2:19 PM, Phil Steitz phil.ste...@gmail.com wrote:

 On 4/29/15 8:59 AM, vijay wrote:
 Hi ,

 I want to know if i can achieve this. Is there any way to specify time
 out
 for the addobject and borrow object methods?

 What i am really looking is when i start the pool i am prefilling it with
 add object for this i can wait for more time to geth the pool
 initialized.
 The backned system i have takes more time to crate connections

 But at the time of borrow i cannot have the client wait for long time if
 no
 idle connection is available and the factory make object method might
 take
 more time to  return object.

 So is there anyway i can tall factory method to wait for x time for add
 obkject and y time for borrow object calls
 There is no timeout for addObject.  It is just a no-op if there is
 no capacity to add to the pool when you call it.  If you are
 prefilling at startup, that should not be a problem.  If you
 actually *want* a timeout for the adds, then you need to implement
 it in your factory itself.

 Phil

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Pool blocking but not hitting max size?

[Phil Steitz]

On 4/13/15 2:39 PM, Dan wrote:
 repeatedly seen this happen and would appreciate some input or advice.
 We're using version 1.6 of the commons pool, I don't believe we could
 upgrade without good reason.
 From the line numbers in the stack trace, it looks like you are
 actually running pool 1.3, which is, well, ancient.  You should
 verify the version and if it is as I suspect, you should definitely
 upgrade.  Just have a look at the change log for the many, many
 issues that have been resolved since 1.3.  That version should be
 deadlock-free, though it achieves that by extreme
 over-synchronization.  Both borrow and return are fully synchronized
 (threads are waiting on the pool monitor in the dump below).
 Version 1.3 is the least performant version of commons pool.
 My apologies, I just searched the .ear we deploy for what I thought
 was the commons pool and found commons-pool-1.6.jar, so I figured that
 was the active version. Now that I look again, there are 20 .jar files
 all containing the word commons in the file name, with varying version
 numbers. Like I said, I'm just a lowly server admin watching this app
 crash.

 Additionally, the maxIdle setting limits the number of instances
 that can be idle in the pool to just 8.  That means that when
 instances are returned and there are already 8 idle, the returning
 instances are destroyed.  When more load arrives, you then have to
 wait for them to be created, which in v 1.3 causes all threads to
 wait on the factory.  If you can afford to have more instances idle,
 you should increase that number.
 In what sense do you say 'afford'? The servers have more than enough
 CPU/RAM available when this happens. Would you expect any meaningful
 overhead from bumping this number up to 50 or 100 during normal
 operations? We have test environments, but have struggled to create
 similar loads to production in them, so it may be difficult to fully
 test this change.

 You will likely get immediate relief by increasing maxIdle to
 several hundred or even the maxActive number; but you really should
 upgrade to a more recent version.  See the pool web page for JDK
 requirements and version compatibility.
 Thanks, I was very surprised when I saw how many versions behind our
 code looked from my naive glancing. I will suggest the maxIdle change
 and go from there.

 Just to clarify, the reason these threads are (likely) blocking is
 that we have 8 idle pool members, so every single request thereafter
 will cause a synchronized construct/destruct which blocks the entire
 pool until it completes, effectively limiting throughput to one
 request at a time until load goes down. I'd just like something
 meaningful to pass onto the developers.

Let me try to explain a little better so you can make the right
decisions before and after upgrade.

The maxActive setting (renamed maxTotal in v. 2) governs the total
number of instances in circulation - checked out or idle waiting to
be checked out - at a given time.  The maxIdle setting limits the
number of instances that can sit idle in the pool.  Given your
settings, a spike in demand could cause 2048 instances to be created
and handed out to clients.  On return, any arriving back when there
were more than 8 instances idle would get destroyed.  In general
maxIdle  maxTotal under variable load will result in a lot of
object creation / destruction.  If your environment can allow
maxIdle == maxTotal (or at least not hugely less), you can avoid
this churn.  Sometimes people want to reallocate resources after
load subsides so they set maxIdle  maxActive.

Now, pool 1.3 makes the pain associated with object churn much worse
because the factory create and destroy methods are executed while
holding *global* locks on the pool.  That means all threads waiting
on borrow or return have to wait for the factory methods to complete.

Morals of the story:

1.  Upgrade to a modern version of pool (1.5.7+) where the factory
methods don't block the pool
2.  Consider setting maxIdle closer or equal to maxActive.

Phil

 I appreciate the input!

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Pool blocking but not hitting max size?

[Phil Steitz]

On 4/13/15 9:36 AM, Dan wrote:
 Hello, I'm not a developer on the project I'm supporting, but I have
 repeatedly seen this happen and would appreciate some input or advice.
 We're using version 1.6 of the commons pool, I don't believe we could
 upgrade without good reason.
From the line numbers in the stack trace, it looks like you are
actually running pool 1.3, which is, well, ancient.  You should
verify the version and if it is as I suspect, you should definitely
upgrade.  Just have a look at the change log for the many, many
issues that have been resolved since 1.3.  That version should be
deadlock-free, though it achieves that by extreme
over-synchronization.  Both borrow and return are fully synchronized
(threads are waiting on the pool monitor in the dump below). 
Version 1.3 is the least performant version of commons pool.

Additionally, the maxIdle setting limits the number of instances
that can be idle in the pool to just 8.  That means that when
instances are returned and there are already 8 idle, the returning
instances are destroyed.  When more load arrives, you then have to
wait for them to be created, which in v 1.3 causes all threads to
wait on the factory.  If you can afford to have more instances idle,
you should increase that number.

You will likely get immediate relief by increasing maxIdle to
several hundred or even the maxActive number; but you really should
upgrade to a more recent version.  See the pool web page for JDK
requirements and version compatibility.

Phil

 We're running WebLogic and periodically see thread count shoot up to
 the work manager maximum, and throughput grinds to a halt. All threads
 are blocked waiting on the commons pool, which I thought was strange
 as heap dumps show output like:

 Type   Name   Value
 intevictLastIndex -1
 ref_evictor   null
 int_numActive 206
 ref_factory
 org.springframework.aop.target.CommonsPoolTargetSource @ 0x610...
 ref_pool  java.util.LinkedList @ 0x610...
 long   _softMinEvictableIdleTimeMillis-1
 long   _minEvictableIdleTimeMillis180
 int_numTestsPerEvictionRun3
 long   _timeBetweenEvictionRunsMillis -1
 boolean_testWhileIdle FALSE
 boolean_testOnReturn  FALSE
 boolean_testOnBorrow  FALSE
 byte   _whenExhaustedAction   1
 long   _maxWait   -1
 int_maxActive 4096
 int_minIdle   10
 int_maxIdle   8
 booleanclosed FALSE

 So from that, I would have expected numActive to be much closer to
 4096 which is the maxActive we set. Am I looking at the wrong place?
 Why is this pool blocking? This has happened multiple times, and each
 time numActive is between 200 and 300. The pool is being used (I believe)
 to limit the number of concurrent security authorizations, so each borrow
 then pings an external service, and that external service does not appear
 overloaded at all.

 I did notice that when I drilled down into the pool's linked list, it
 only ever has 8 members in it, I would have expected numActive members
 at least. I don't fully understand the pool though.

 Here's a partial thread dump showing this behavior (addresses truncated,
 but they all blocked on the same pool object):

 [ACTIVE] ExecuteThread: '160' for queue: 'weblogic.kernel.Default
 (self-tuning)' daemon prio=10 tid=0x000... nid=0x4b1f
 waiting for monitor entry [0x000...]
java.lang.Thread.State: BLOCKED (on object monitor)
 at org.apache.commons.pool.impl.GenericObjectPool.returnObject(
 GenericObjectPool.java:916)
 - waiting to lock 0x000... (a
 org.apache.commons.pool.impl.GenericObjectPool)
 at org.springframework.aop.target.CommonsPoolTargetSource.
 releaseTarget(CommonsPoolTargetSource.java:252)
 --
 [ACTIVE] ExecuteThread: '159' for queue: 'weblogic.kernel.Default
 (self-tuning)' daemon prio=10 tid=0x... nid=0x4b1e
 waiting for monitor entry [0x000...]
java.lang.Thread.State: BLOCKED (on object monitor)
 at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(
 GenericObjectPool.java:781)
 - waiting to lock 0x000... (a
 org.apache.commons.pool.impl.GenericObjectPool)
 at org.springframework.aop.target.CommonsPoolTargetSource.getTarget(
 CommonsPoolTargetSource.java:244)
 --
 [ACTIVE] ExecuteThread: '158' for queue: 'weblogic.kernel.Default
 (self-tuning)' daemon prio=10 tid=0x000... nid=0x4b1d
 waiting for monitor entry [0x000...]
java.lang.Thread.State: BLOCKED (on object monitor)
 at org.apache.commons.pool.impl.GenericObjectPool.returnObject(
 GenericObjectPool.java:916)
 - waiting to lock 0x000... (a
 org.apache.commons.pool.impl.GenericObjectPool)
 at org.springframework.aop.target.CommonsPoolTargetSource.
 releaseTarget(CommonsPoolTargetSource.java

Re: [POOL] Release 2.3 in JIRA

[Michael Osipov]

Am 2015-02-08 um 22:03 schrieb Phil Steitz:

On 2/8/15 1:44 PM, Michael Osipov wrote:

Hi,

can anyone kindly release 2.3 in JIRA. It is still in the roadmap
and not in the changelog.


Done.  Thanks for pointing this out.  The changelog we pay attention
to / keep always up to date, is in /src/changes/changes.xml, which
appears on the website at [1].


Is there any reason not the use the JIRA report from MCHANGES? This 
works quite well with several Maven projects. I have added several 
improvements to it as well as the skin you are using. You should give it 
a try.


Michael


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[POOL] Release 2.3 in JIRA

[Michael Osipov]

Hi,

can anyone kindly release 2.3 in JIRA. It is still in the roadmap and 
not in the changelog.


Michael

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [POOL] Release 2.3 in JIRA

[Phil Steitz]

On 2/8/15 1:44 PM, Michael Osipov wrote:
 Hi,

 can anyone kindly release 2.3 in JIRA. It is still in the roadmap
 and not in the changelog.

Done.  Thanks for pointing this out.  The changelog we pay attention
to / keep always up to date, is in /src/changes/changes.xml, which
appears on the website at [1].

Phil

[1] http://commons.apache.org/proper/commons-pool/changes-report.html

 Michael

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [POOL] Release 2.3 in JIRA

[sebb]

On 8 February 2015 at 21:33, Michael Osipov 1983-01...@gmx.net wrote:
 Am 2015-02-08 um 22:03 schrieb Phil Steitz:

 On 2/8/15 1:44 PM, Michael Osipov wrote:

 Hi,

 can anyone kindly release 2.3 in JIRA. It is still in the roadmap
 and not in the changelog.


 Done.  Thanks for pointing this out.  The changelog we pay attention
 to / keep always up to date, is in /src/changes/changes.xml, which
 appears on the website at [1].


 Is there any reason not the use the JIRA report from MCHANGES? This works
 quite well with several Maven projects. I have added several improvements to
 it as well as the skin you are using. You should give it a try.


There may be changes to report that don't have JIRAs.

Furthermore, changes.xml can be used to create the Release Notes automatically.

Also the JIRA changes report does not show all the entries if there
are more matching changes than the API limit (which is fixed at 100).

See https://jira.codehaus.org/browse/MCHANGES-351

But we do use the JIRA report as well.

 Michael


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[dbcp] SQLException: Error preloading the connection pool after upgrade to commons-dbcp2

[Cuenca, Sergio]

TITLE: SQLException: Error preloading the connection pool after upgrade to 
commons-dbcp2
ENVIRONTMENT:

  *   Windows XP
  *   Junit 4.11
  *   Java 1.7
  *   Spring 4.0
  *   maven-compiler-plugin 3.2
  *   maven.surefire.plugin 2.17
  *   maven-cobertura-plugin 2.6
  *   Jenkins 1.549
RELATED ISSUE: https://issues.apache.org/jira/browse/DBCP-431?filter=-2
DESCRIPTION:

Hi all,
We have a continuous integration environment (Jenkins) to launch our JUnits 
tests.
We had the version 1.4 of commons-dbcp to create the connection pools with 
Spring. The configuration was the following:

bean id=dataSourceTemplate class=org.apache.commons.dbcp.BasicDataSource 
destroy-method=close
  property 
name=driverClassNamevalue${aplicacion.datasource.driverClassName}/value/property
  property 
name=urlvalue${aplicacion.datasource.url}/value/property
  property 
name=usernamevalue${aplicacion.datasource.user}/value/property
  property 
name=passwordvalue${aplicacion.datasource.password}/value/property
  property name=initialSizevalue1/value/property
  property name=maxActivevalue15/value/property
  property name=maxIdlevalue2/value/property
  property 
name=accessToUnderlyingConnectionAllowedvalue${aplicacion.datasource.accessToUnderlyingConnectionAllowed}/value/property
/bean

We use JUnit 4.11 and maven cobertura plugin 1.6. to launch the tests.
This configuration was working CORRECTLY.
After upgrade to commons-dbcp2, version 2.0.1. Some unit tests are reporting 
errors with the following message:
java.sql.SQLException: Error preloading the connection pool.
We launch one unit test each time, one by one. We create and destroy the 
connection pool every time.
What can we do to solve this problem??

Thank you very much.


Sergio Cuenca Guirado
RD Department
Logister, S.A. - GRIFOLS
Polígon Llevant
C/Palou, 6
08150 Parets del Vallès
Tel: + 34 93 571 02 78
Fax: + 34 93 571 02 94

P  Do you need to print this message? Let's protect the environment.


La información contenida en el presente e-mail es confidencial y está reservada 
para el uso exclusivo de su destinatario. Se prohíbe estrictamente la 
distribución, copia o utilización de esta información sin el previo permiso de 
su destinatario. Si usted no fuera el destinatario, por favor notifíquelo 
inmediatamente al remitente y elimine el presente mensaje de su sistema 
informático.

Information contained in this e-mail is confidential and is intended for the 
use of the addressee only. Any dissemination, distribution, copying or use of 
this communication without prior permission of the addressee is strictly 
prohibited. If you are not the intended addressee, please notify the sender 
immediately by reply and then delete this message from your computer system.

Re: [dbcp] SQLException: Error preloading the connection pool after upgrade to commons-dbcp2

[Phil Steitz]

On 1/27/15 5:56 AM, Cuenca, Sergio wrote:
 TITLE: SQLException: Error preloading the connection pool after upgrade to 
 commons-dbcp2
 ENVIRONTMENT:

   *   Windows XP
   *   Junit 4.11
   *   Java 1.7
   *   Spring 4.0
   *   maven-compiler-plugin 3.2
   *   maven.surefire.plugin 2.17
   *   maven-cobertura-plugin 2.6
   *   Jenkins 1.549
 RELATED ISSUE: https://issues.apache.org/jira/browse/DBCP-431?filter=-2
 DESCRIPTION:

 Hi all,
 We have a continuous integration environment (Jenkins) to launch our JUnits 
 tests.
 We had the version 1.4 of commons-dbcp to create the connection pools with 
 Spring. The configuration was the following:

 bean id=dataSourceTemplate class=org.apache.commons.dbcp.BasicDataSource 
 destroy-method=close
   property 
 name=driverClassNamevalue${aplicacion.datasource.driverClassName}/value/property
   property 
 name=urlvalue${aplicacion.datasource.url}/value/property
   property 
 name=usernamevalue${aplicacion.datasource.user}/value/property
   property 
 name=passwordvalue${aplicacion.datasource.password}/value/property
   property name=initialSizevalue1/value/property
   property name=maxActivevalue15/value/property
   property name=maxIdlevalue2/value/property
   property 
 name=accessToUnderlyingConnectionAllowedvalue${aplicacion.datasource.accessToUnderlyingConnectionAllowed}/value/property
 /bean

 We use JUnit 4.11 and maven cobertura plugin 1.6. to launch the tests.
 This configuration was working CORRECTLY.
 After upgrade to commons-dbcp2, version 2.0.1. Some unit tests are reporting 
 errors with the following message:
 java.sql.SQLException: Error preloading the connection pool.
 We launch one unit test each time, one by one. We create and destroy the 
 connection pool every time.
 What can we do to solve this problem??

Are you sure the tests are not running concurrently?   See comment
on the JIRA.  I think there may be a bug lurking here.

Phil

 Thank you very much.


 Sergio Cuenca Guirado
 RD Department
 Logister, S.A. - GRIFOLS
 Polígon Llevant
 C/Palou, 6
 08150 Parets del Vallès
 Tel: + 34 93 571 02 78
 Fax: + 34 93 571 02 94

 P  Do you need to print this message? Let's protect the environment.


 La información contenida en el presente e-mail es confidencial y está 
 reservada para el uso exclusivo de su destinatario. Se prohíbe estrictamente 
 la distribución, copia o utilización de esta información sin el previo 
 permiso de su destinatario. Si usted no fuera el destinatario, por favor 
 notifíquelo inmediatamente al remitente y elimine el presente mensaje de su 
 sistema informático.

 Information contained in this e-mail is confidential and is intended for the 
 use of the addressee only. Any dissemination, distribution, copying or use of 
 this communication without prior permission of the addressee is strictly 
 prohibited. If you are not the intended addressee, please notify the sender 
 immediately by reply and then delete this message from your computer system.



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [dbcp] SQLException: Error preloading the connection pool after upgrade to commons-dbcp2

[Benedikt Ritter]

Hello Sergio,

2015-01-27 13:56 GMT+01:00 Cuenca, Sergio 
sergio.cue...@external.grifols.com:

 TITLE: SQLException: Error preloading the connection pool after upgrade to
 commons-dbcp2
 ENVIRONTMENT:

   *   Windows XP
   *   Junit 4.11
   *   Java 1.7
   *   Spring 4.0
   *   maven-compiler-plugin 3.2
   *   maven.surefire.plugin 2.17
   *   maven-cobertura-plugin 2.6
   *   Jenkins 1.549
 RELATED ISSUE: https://issues.apache.org/jira/browse/DBCP-431?filter=-2
 DESCRIPTION:

 Hi all,
 We have a continuous integration environment (Jenkins) to launch our
 JUnits tests.
 We had the version 1.4 of commons-dbcp to create the connection pools with
 Spring. The configuration was the following:

 bean id=dataSourceTemplate
 class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
   property
 name=driverClassNamevalue${aplicacion.datasource.driverClassName}/value/property
   property
 name=urlvalue${aplicacion.datasource.url}/value/property
   property
 name=usernamevalue${aplicacion.datasource.user}/value/property
   property
 name=passwordvalue${aplicacion.datasource.password}/value/property
   property name=initialSizevalue1/value/property
   property name=maxActivevalue15/value/property
   property name=maxIdlevalue2/value/property
   property
 name=accessToUnderlyingConnectionAllowedvalue${aplicacion.datasource.accessToUnderlyingConnectionAllowed}/value/property
 /bean

 We use JUnit 4.11 and maven cobertura plugin 1.6. to launch the tests.
 This configuration was working CORRECTLY.
 After upgrade to commons-dbcp2, version 2.0.1. Some unit tests are
 reporting errors with the following message:
 java.sql.SQLException: Error preloading the connection pool.
 We launch one unit test each time, one by one. We create and destroy the
 connection pool every time.
 What can we do to solve this problem??


How does your new configuration look? The FQCN of BasicDataSource now is
org.apache.commons.dbcp2.BasicDataSource. Do you have two versions of dbcp
in your classpath after your update?

Benedikt



 Thank you very much.


 Sergio Cuenca Guirado
 RD Department
 Logister, S.A. - GRIFOLS
 Polígon Llevant
 C/Palou, 6
 08150 Parets del Vallès
 Tel: + 34 93 571 02 78
 Fax: + 34 93 571 02 94

 P  Do you need to print this message? Let's protect the environment.


 La información contenida en el presente e-mail es confidencial y está
 reservada para el uso exclusivo de su destinatario. Se prohíbe
 estrictamente la distribución, copia o utilización de esta información sin
 el previo permiso de su destinatario. Si usted no fuera el destinatario,
 por favor notifíquelo inmediatamente al remitente y elimine el presente
 mensaje de su sistema informático.

 Information contained in this e-mail is confidential and is intended for
 the use of the addressee only. Any dissemination, distribution, copying or
 use of this communication without prior permission of the addressee is
 strictly prohibited. If you are not the intended addressee, please notify
 the sender immediately by reply and then delete this message from your
 computer system.




-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

[ANNOUNCEMENT] Apache Commons Pool 2.3 released

[Phil Steitz]

The Apache Commons Team is pleased to announce the release of Apache
Commons Pool 2.3.

The Apache Commons Pool open source software library provides an
object-pooling API and a number of object pool implementations.

No client code changes are required to migrate from any of the 2.x
versions to 2.3. Users of version 1.x should consult the migration
guide on the Commons Pool web site.

Source and binary distributions are available for download from the
Apache Commons download site:
http://commons.apache.org/proper/commons-pool/download_pool.cgi

When downloading, please verify signatures using the KEYS file
available at the above location.

Full details of all the changes in 2.3 can be found in the changelog:
http://commons.apache.org/proper/commons-pool/changes-report.html

For complete information on Commons Pool, including instructions on
how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Pool website:
http://commons.apache.org/proper/commons-pool/

Phil Steitz, on behalf of the Apache Commons community


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[pool] [dbcp] Re: evictor destroying connections below minIdle?

[Phil Steitz]

On 10/17/14 5:38 PM, Anthony Biacco wrote:
 I just started running pool 2.2 alongside dbcp 2.0.1 in tomcat 7 against
 mysql.

 I noticed a situation while running the idle evictor where there's a time
 during eviction where the number of connections drops below the value set
 for minIdle, so in theory if all connections were idle for
 minEvictableIdleTimeMillis, i could have no free connections.
 After the eviction, connections seem to be created back up to minIdle.

 I expected it to only evict down to the minIdle value, not evict all
 eligible idle connections and then recreate up to minIdle.
 The way i'm viewing the number of connections is through mysql's show full
 processlist command.
 Is what i'm describing possible or am I missing something?

Yes, this is possible.  When evicting idle instances due to
minEvictableIdleTimeMillis exceeded, the evictor does not take into
account the number of idle instances remaining in the pool and it
performs the evict, ensure min idle actions in sequence.  If you
want to avoid the destroy / recreate scenario, you can use
softMinEvictableIdleTimeMillis instead.  
 If it is possible, couldn't this cause the resource to become unavailable
 in the time between destruction and recreation?

I am not sure what you mean here.  This could lead to the idle
instance count hitting zero, but client threads will still get
served as long as maxTotal is not exceeded.  Client threads will
create instances to serve requests when the pool is empty, as long
as there is capacity to do so, and evictor destroy actions
immediately create capacity.  Borrowers may have to incur makeObject
(create physical connection in DBCP case) latency, but they will get
served.

Phil



 Here's my config:
 initialSize=15
 minIdle=15
 maxIdle=100
 maxTotal=200
 maxWaitMillis=4000
 defaultQueryTimeout=20
 testOnBorrow=true
 testWhileIdle=true
 blockWhenExhausted=true
 numTestsPerEvictionRun=50
 timeBetweenEvictionRunsMillis=12
 minEvictableIdleTimeMillis=119000
 validationQuery=SELECT 1
 validationQueryTimeout=2
 removeAbandoned=true
 removeAbandonedOnBorrow=true
 removeAbandonedTimeout=60
 logAbandoned=true

 Thanks,

 -Tony




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] [dbcp] Re: evictor destroying connections below minIdle?

[Anthony Biacco]

On Oct 18, 2014 9:46 AM, Phil Steitz phil.ste...@gmail.com wrote:

 On 10/17/14 5:38 PM, Anthony Biacco wrote:

 Yes, this is possible.  When evicting idle instances due to
 minEvictableIdleTimeMillis exceeded, the evictor does not take into
 account the number of idle instances remaining in the pool and it
 performs the evict, ensure min idle actions in sequence.  If you
 want to avoid the destroy / recreate scenario, you can use
 softMinEvictableIdleTimeMillis instead.

Ok thanks, I'll try using that.

  If it is possible, couldn't this cause the resource to become
unavailable
  in the time between destruction and recreation?

 I am not sure what you mean here.  This could lead to the idle
 instance count hitting zero, but client threads will still get
 served as long as maxTotal is not exceeded.

Sorry, you're right, don't know what I was thinking. More beer!

Thanks for the help.

-Tony

[pool]

[Ashish Chaudhary]

I am getting this error  *INFO: Maximum number of threads (200) created
for connector with address null and port 8080*  on prod in approximately
every 7-8 days. So to debug this issue I downloaded the thread dump file.
This file has following thread state 100 times:

http-8080-198 daemon prio=10 tid=0x08a62c00 nid=0x3a78 in Object.wait()
[0x66467000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0x87097728 (a
org.apache.commons.pool.impl.GenericObjectPool$Latch)
at java.lang.Object.wait(Object.java:485)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
- locked 0x87097728 (a
org.apache.commons.pool.impl.GenericObjectPool$Latch)

My understanding is that there is some memory leak or the connection
objects are not enough and because of this every call waits for new MySQL
connection from the pool and it just hangs there and the thread associated
with this MySQL call also waits. And this leads to this issue *INFO:
Maximum number of threads (200) created for connector with address null and
port 8080*

So my questions are:

Is this exception because of mysql connection pool? If yes, what should
I do to solve it? My MAX-Active value is 50 and MinIdle value is 1.

If this is not the case then how can I know which functionality are
holding threads?

Note: I'm not closing ResultSet, I'm closing only Statement and Connection
can this might be the issue.

Re: [pool]

[Gary Gregory]

Have you tried pool2?

Gary

On Wed, Oct 1, 2014 at 4:46 AM, Ashish Chaudhary 
ashishchaudhar...@gmail.com wrote:

 I am getting this error  *INFO: Maximum number of threads (200) created
 for connector with address null and port 8080*  on prod in approximately
 every 7-8 days. So to debug this issue I downloaded the thread dump file.
 This file has following thread state 100 times:

 http-8080-198 daemon prio=10 tid=0x08a62c00 nid=0x3a78 in Object.wait()
 [0x66467000]
java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on 0x87097728 (a
 org.apache.commons.pool.impl.GenericObjectPool$Latch)
 at java.lang.Object.wait(Object.java:485)
 at

 org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
 - locked 0x87097728 (a
 org.apache.commons.pool.impl.GenericObjectPool$Latch)

 My understanding is that there is some memory leak or the connection
 objects are not enough and because of this every call waits for new MySQL
 connection from the pool and it just hangs there and the thread associated
 with this MySQL call also waits. And this leads to this issue *INFO:
 Maximum number of threads (200) created for connector with address null and
 port 8080*

 So my questions are:

 Is this exception because of mysql connection pool? If yes, what should
 I do to solve it? My MAX-Active value is 50 and MinIdle value is 1.

 If this is not the case then how can I know which functionality are
 holding threads?

 Note: I'm not closing ResultSet, I'm closing only Statement and Connection
 can this might be the issue.




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[pool] Validation code invoked on unexpected timing.

[Noriyuki Torii]

Hi, all.

I found BasePooledObjectFactory.validateObject() of commons-pool
sometimes called
on unexpected timing and I cannot identify the cause.
So I would like to ask some advice.

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.

I also attach small reproduction code below.
Can anyone tell it is because some lack of configurations, or, actual
pool's bug?

Thanks in advance.

Noriyuki Torii


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 BasePooledObjectFactoryMyPooledObj
{
@Override
public MyPooledObj create() {
return new MyPooledObj();
}

@Override
public PooledObjectMyPooledObj wrap(MyPooledObj o) {
return new DefaultPooledObjectMyPooledObj(o);
}

@Override
public boolean validateObject(PooledObjectMyPooledObj 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 GenericObjectPoolMyPooledObj pool =
new GenericObjectPoolMyPooledObj(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();
}
}

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] Validation code invoked on unexpected timing.

[Noriyuki Torii]

Hi, Phil.
Thanks for your response.

I opened a ticket for this issue as POOL-276.
In fact, I am a newbie of JIRA.  So if there are any mistakes on this
ticket, please let me know.

Regards,

2014-09-04 10:35 GMT+09:00 Phil Steitz phil.ste...@gmail.com:
 On 9/3/14 9:27 AM, Noriyuki Torii wrote:
 Hi, all.

 I found BasePooledObjectFactory.validateObject() of commons-pool
 sometimes called
 on unexpected timing and I cannot identify the cause.
 So I would like to ask some advice.

 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.

 I also attach small reproduction code below.
 Can anyone tell it is because some lack of configurations, or, actual
 pool's bug?

 Thanks for reporting this.  Looks like it could be a pool bug.  Do
 you mind opening a JIRA ticket for this?

 Phil

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [POOL-276] Validation code invoked on unexpected timing.

[Bernd Eckenfels]

Hello,

your JIRA report looks good! I took the liberty to modify
it a bit and included JIRA markup {code} before and after the code, so
it does do formatting and syntax highliting.

BTW: I added some more print in my local version of your reproducer and
adding the thread name, so it is clear when things are happening. The
output reproduces the following sequence:

1409804599167 mainCreated 0 
379cbef5-3e40-4f39-af5f-ac3e76506e81
1409804599229 mainWrapped 0 
379cbef5-3e40-4f39-af5f-ac3e76506e81
1409804599229 main  Validated 1 
379cbef5-3e40-4f39-af5f-ac3e76506e81
1409804599229 main   Borrowed 1 
379cbef5-3e40-4f39-af5f-ac3e76506e81
1409804602256 Timer-0   Returning 1 
379cbef5-3e40-4f39-af5f-ac3e76506e81
1409804602256 main  Validated 2 
379cbef5-3e40-4f39-af5f-ac3e76506e81
1409804602256 main Borrowed Again 2 
379cbef5-3e40-4f39-af5f-ac3e76506e81

Just in case anybody wondered, it is happening after the return in the borrow 
thread.

Gruss
Bernd


 Am Thu, 4 Sep 2014 12:27:39
+0900 schrieb Noriyuki Torii torii7...@gmail.com:

 Hi, Phil.
 Thanks for your response.
 
 I opened a ticket for this issue as POOL-276.
 In fact, I am a newbie of JIRA.  So if there are any mistakes on this
 ticket, please let me know.
 
 Regards,
 
 2014-09-04 10:35 GMT+09:00 Phil Steitz phil.ste...@gmail.com:
  On 9/3/14 9:27 AM, Noriyuki Torii wrote:
  Hi, all.
 
  I found BasePooledObjectFactory.validateObject() of commons-pool
  sometimes called
  on unexpected timing and I cannot identify the cause.
  So I would like to ask some advice.
 
  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.
 
  I also attach small reproduction code below.
  Can anyone tell it is because some lack of configurations, or,
  actual pool's bug?
 
  Thanks for reporting this.  Looks like it could be a pool bug.  Do
  you mind opening a JIRA ticket for this?
 
  Phil
 
 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org
 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [dbcp] How to create replication aware connection pool ?

[Parth Patil]

Hi Mark,
Thanks a lot. Setting validation query on BasicDataSource fixed the problem!

ds.setValidationQuery(SELECT 1)


On Wed, Aug 6, 2014 at 1:15 AM, Mark Thomas ma...@apache.org wrote:

 On 06/08/2014 01:34, Parth Patil wrote:
  Hi Friends,
  I am using DBCP2 in my project and I am pleased with the performance of
 the
  library. Though I am only able to provide a single mysql host in the
  connection string. What do I need to do inorder to make the DBCP
 connection
  pool replication aware ?

 Write some code :). DBCP 2 is not replication aware. There was an
 enhancement request for this [1] but I resolved it as WONTFIX on the
 bases that:
 quote
 ...generally, failover requires some form of database replication and
 databases that provide that tend to provide JDBC drivers that support
 failover as well.
 /quote

  I am going to use 1 master and 2 slaves in my
  setup. Am I correct in assuming that its possible to create connection
 pool
  over several mysql hosts ?

 No, you are not correct.

  I tried to use the replication aware mysql jdbc driver
  (com.mysql.jdbc.ReplicationDriver)

 That is the correct way to do this.

  but that doesn't seem to work and I am
  getting an exception. Following is my test code

 snip/

  Following is the exception that I am getting :
 
  [error] (run-main-0) java.lang.AbstractMethodError:
  com.mysql.jdbc.ReplicationConnection.isValid(I)Z

 snip/

 DBCP2 uses JDBC4 (Java 1.6) and that is a new method introduced in that
 release.

 You can avoid the call to that method by setting a validation query for
 your connection pool. For MySQL the following should work:
 /* ping */ SELECT 1


 Mark

 [1] https://issues.apache.org/jira/browse/DBCP-393

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org




-- 
Best,
Parth

Re: [dbcp] How to create replication aware connection pool ?

[Mark Thomas]

On 06/08/2014 01:34, Parth Patil wrote:
 Hi Friends,
 I am using DBCP2 in my project and I am pleased with the performance of the
 library. Though I am only able to provide a single mysql host in the
 connection string. What do I need to do inorder to make the DBCP connection
 pool replication aware ?

Write some code :). DBCP 2 is not replication aware. There was an
enhancement request for this [1] but I resolved it as WONTFIX on the
bases that:
quote
...generally, failover requires some form of database replication and
databases that provide that tend to provide JDBC drivers that support
failover as well.
/quote

 I am going to use 1 master and 2 slaves in my
 setup. Am I correct in assuming that its possible to create connection pool
 over several mysql hosts ?

No, you are not correct.

 I tried to use the replication aware mysql jdbc driver
 (com.mysql.jdbc.ReplicationDriver)

That is the correct way to do this.

 but that doesn't seem to work and I am
 getting an exception. Following is my test code

snip/

 Following is the exception that I am getting :
 
 [error] (run-main-0) java.lang.AbstractMethodError:
 com.mysql.jdbc.ReplicationConnection.isValid(I)Z

snip/

DBCP2 uses JDBC4 (Java 1.6) and that is a new method introduced in that
release.

You can avoid the call to that method by setting a validation query for
your connection pool. For MySQL the following should work:
/* ping */ SELECT 1


Mark

[1] https://issues.apache.org/jira/browse/DBCP-393

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [dbcp] How to create replication aware connection pool ?

[Phil Steitz]

On 8/6/14 1:15 AM, Mark Thomas wrote:
 On 06/08/2014 01:34, Parth Patil wrote:
 Hi Friends,
 I am using DBCP2 in my project and I am pleased with the performance of the
 library. Though I am only able to provide a single mysql host in the
 connection string. What do I need to do inorder to make the DBCP connection
 pool replication aware ?
 Write some code :). DBCP 2 is not replication aware. There was an
 enhancement request for this [1] but I resolved it as WONTFIX on the
 bases that:
 quote
 ...generally, failover requires some form of database replication and
 databases that provide that tend to provide JDBC drivers that support
 failover as well.
 /quote

 I am going to use 1 master and 2 slaves in my
 setup. Am I correct in assuming that its possible to create connection pool
 over several mysql hosts ?
 No, you are not correct.

 I tried to use the replication aware mysql jdbc driver
 (com.mysql.jdbc.ReplicationDriver)
 That is the correct way to do this.

 but that doesn't seem to work and I am
 getting an exception. Following is my test code
 snip/

 Following is the exception that I am getting :

 [error] (run-main-0) java.lang.AbstractMethodError:
 com.mysql.jdbc.ReplicationConnection.isValid(I)Z
 snip/

 DBCP2 uses JDBC4 (Java 1.6) and that is a new method introduced in that
 release.

I think you mean JDBC 4.1, Java 1.7 for DBCP2.

Phil

 You can avoid the call to that method by setting a validation query for
 your connection pool. For MySQL the following should work:
 /* ping */ SELECT 1


 Mark

 [1] https://issues.apache.org/jira/browse/DBCP-393

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[dbcp] How to create replication aware connection pool ?

[Parth Patil]

Hi Friends,
I am using DBCP2 in my project and I am pleased with the performance of the
library. Though I am only able to provide a single mysql host in the
connection string. What do I need to do inorder to make the DBCP connection
pool replication aware ? I am going to use 1 master and 2 slaves in my
setup. Am I correct in assuming that its possible to create connection pool
over several mysql hosts ?

I tried to use the replication aware mysql jdbc driver
(com.mysql.jdbc.ReplicationDriver) but that doesn't seem to work and I am
getting an exception. Following is my test code

import org.apache.commons.dbcp2.BasicDataSource;
import java.sql.Connection;
import java.sql.Statement;
import java.sql.ResultSet;

public class MyJdbcTest {
public static void main(String[] args)  throws Exception {
String connectionString =
jdbc:mysql:replication://localhost,localhost/my_database;
String driverName = com.mysql.jdbc.ReplicationDriver;

BasicDataSource ds = new BasicDataSource();
ds.setDriverClassName(driverName);
ds.setUsername(root);
ds.setUrl(connectionString);

Connection conn = ds.getConnection();
Statement stmt = conn.createStatement();

ResultSet resultSet = stmt.executeQuery(SELECT * FROM PERSONS
LIMIT 1);
int numCols = resultSet.getMetaData().getColumnCount();

while(resultSet.next()) {
for(int i = 1; i  numCols ; i++) {
System.out.println(\t + resultSet.getString(i));
}
}
}
}


Following is the exception that I am getting :

[error] (run-main-0) java.lang.AbstractMethodError:
com.mysql.jdbc.ReplicationConnection.isValid(I)Z
java.lang.AbstractMethodError:
com.mysql.jdbc.ReplicationConnection.isValid(I)Z
at
org.apache.commons.dbcp2.DelegatingConnection.isValid(DelegatingConnection.java:914)
at
org.apache.commons.dbcp2.PoolableConnection.validate(PoolableConnection.java:227)
at
org.apache.commons.dbcp2.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:303)
at
org.apache.commons.dbcp2.BasicDataSource.validateConnectionFactory(BasicDataSource.java:2165)
at
org.apache.commons.dbcp2.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:2148)
at
org.apache.commons.dbcp2.BasicDataSource.createDataSource(BasicDataSource.java:1903)
at
org.apache.commons.dbcp2.BasicDataSource$PaGetConnection.run(BasicDataSource.java:2267)
at
org.apache.commons.dbcp2.BasicDataSource$PaGetConnection.run(BasicDataSource.java:2263)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.commons.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1404)
at com.stumbleupon.pd.test.MyJdbcTest.main(MyJdbcTest.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)




-- 
Best,
Parth

Re: Multiplexed connections in commons pool

[Phil Steitz]

On 6/19/14, 2:36 PM, James Leskovar wrote:
 Hi Phil,

 Thanks for the reply. I'll try my hand first at the PairConn,Int approach, 
 and if it looks workable I can open up a Jira issue.

Great!  Feel free to ask questions if things don't fall into place
easily. 

Phil

 Cheers,
 James


 -Original Message-
 From: Phil Steitz [mailto:phil.ste...@gmail.com] 
 Sent: Thursday, 19 June 2014 12:24 PM
 To: Commons Users List
 Subject: Re: Multiplexed connections in commons pool

 On 6/18/14, 4:07 PM, James Leskovar wrote:
 Hi there,

  

 I have an application that needs to perform connection pooling, with 
 the proviso that it's okay - and actually preferable - for more than 
 one client to checkout and use the same connection object from the 
 pool. Ideally, I would also like to limit the number of concurrent 
 clients that are using a single connection object. I'm wondering what 
 the best way to do this is. As a quick and dirty option, I suppose I 
 could basically have my PooledObjectFactory return the same objects 
 from makeObject(), and manually keep track of objects from inside my 
 implementation.
 Thoughts?

 This is an interesting use case that unfortunately is that easy to support in 
 [pool].  If you are interested in helping design and implement direct 
 support, please feel free to hop over to the dev list and open a JIRA.

 Your idea of just having the factory return identical instances won't work 
 because when clients return them, they will get exceptions because repeated 
 returns of the same object violates the
 pool contract.   You can make that approach work though by having
 your factory source Foo, int pairs where Foo is what you want to pool.  
 Just make sure the FooInt instances are distinguishable by equals.  
 Unfortunately, your factory will have to maintain counters, which it can do 
 via the lifecycle methods and probably a hashmap keyed on the actual Foo 
 instances with rep counts as values.

 Phil
  

 Cheers,

 *James Leskovar*
 Software Engineer, Location Platforms

 TeleCommunication Systems, Inc.

 [ *Address* : TCS, iC Enterprise 1, Innovation Campus, Squires Way, 
 Nth Wollongong, NSW, 2500, Australia ] [ *Tel* : +61 2 4221 2940 ] [ 
 *Fax* : +61 2 4221 2901 ] [ *Email* : james.lesko...@telecomsys.com 
 mailto:james.lesko...@telecomsys.com ]

 TCS http://www.telecomsys.com/default.aspxFacebook
 https://www.facebook.com/pages/TCS/340389379402958Twitter
 https://twitter.com/TeleComSysLinkedIn
 http://www.linkedin.com/company/telecommunication-systems

  

 CONFIDENTIALITY NOTICE: The information contained in this message may 
 be privileged and/or confidential. If you are not the intended 
 recipient, or responsible for delivering this message to the intended 
 recipient, any review, forwarding, dissemination, distribution or 
 copying of this communication or any attachment(s) is strictly 
 prohibited. If you have received this message in error, please notify 
 the sender immediately, and delete it and all attachments from your 
 computer and network.


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org


 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Multiplexed connections in commons pool

[James Leskovar]

Hi there,

I have an application that needs to perform connection pooling, with the 
proviso that it's okay - and actually preferable - for more than one client to 
checkout and use the same connection object from the pool. Ideally, I would 
also like to limit the number of concurrent clients that are using a single 
connection object. I'm wondering what the best way to do this is. As a quick 
and dirty option, I suppose I could basically have my PooledObjectFactory 
return the same objects from makeObject(), and manually keep track of objects 
from inside my implementation. Thoughts?

Cheers,
James Leskovar
Software Engineer, Location Platforms
TeleCommunication Systems, Inc.

[ Address : TCS, iC Enterprise 1, Innovation Campus, Squires Way, Nth 
Wollongong, NSW, 2500, Australia ]
[ Tel : +61 2 4221 2940 ] [ Fax : +61 2 4221 2901 ]
[ Email : james.lesko...@telecomsys.commailto:james.lesko...@telecomsys.com ]
[TCS]http://www.telecomsys.com/default.aspx[Facebook]https://www.facebook.com/pages/TCS/340389379402958[Twitter]https://twitter.com/TeleComSys[LinkedIn]http://www.linkedin.com/company/telecommunication-systems


CONFIDENTIALITY NOTICE: The information contained in this message may be 
privileged and/or confidential. If you are not the intended recipient, or 
responsible for delivering this message to the intended recipient, any review, 
forwarding, dissemination, distribution or copying of this communication or any 
attachment(s) is strictly prohibited. If you have received this message in 
error, please notify the sender immediately, and delete it and all attachments 
from your computer and network.

[dbcp] - How to programmatically check the pool status?

[Raffaele Gambelli]

Hi all,

I'm using Tomcat 6.0.26 and its default dbcp connection pooling system 
(tomcat-dbcp.jar inside the default installation dir)


My question is:
How could I check programmatically the connection pool status ? For 
example inside a catch of some exception related to some database issues 
I would like to log some info like the number of currenlty open 
connections, idle etc...


Thanks in advance and best regards

Raffaele Gambelli

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[dbcp] - How to programmatically check the pool status?

[Raffaele Gambelli]

Hi all,

I'm using Tomcat 6.0.26 and its default dbcp connection pooling system 
(tomcat-dbcp.jar inside the default installation dir)


My question is:
How could I check programmatically the connection pool status ? For 
example inside a catch of some exception related to some database issues 
I would like to log some info like the number of currenlty open 
connections, idle etc...


Thanks in advance and best regards

--

Raffaele Gambelli

_*Gecod s.r.l.*_ http://gecod.com/it/contatti/index.do

/Development Area/

phone: +39 051 4075795

fax: +39 051.9525291

e-mail: _rgambelli@gecod.com_ mailto:rgambe...@gecod.com

web: _www.gecod.com_ http://www.gecod.com/

skype-id: _rgambelli.gecod_ skype:rgambelli.gecod?add


/Gecod s.r.l. - Tutti i diritti riservati./

/Il presente messaggio e i documenti allegati possono contenere 
informazioni di carattere confidenziale o riservato. Qualora non foste i 
destinatari, vogliate immediatamente informarci via e-mail ed eliminare 
il messaggio, con gli eventuali allegati senza trattenerne copia./



/Gecod s.r.l. - All rights reserved./

/This message and the enclosed documents may contain information which 
is confidential or privileged. If you are not the intended recipient, 
please advise the sender immediately by reply e-mail and delete this 
message and any attachments without retaining a copy./

Re: [dbcp] - How to programmatically check the pool status?

[Phil Steitz]

On 4/16/14, 2:33 AM, Raffaele Gambelli wrote:
 Hi all,

 I'm using Tomcat 6.0.26 and its default dbcp connection pooling
 system (tomcat-dbcp.jar inside the default installation dir)

 My question is:
 How could I check programmatically the connection pool status ?
 For example inside a catch of some exception related to some
 database issues I would like to log some info like the number of
 currenlty open connections, idle etc...

Have a look at the javadoc for BasicDatasource for the version that
tomcat 6 is using (some 1.x version).  There are getters for the
number of active and idle connections.  You may need to cast the
reference that tomcat gives you to the datasource to use these
methods.  You may want to ask about this on the tomcat user list.

Phil

 Thanks in advance and best regards

 Raffaele Gambelli

 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[pool][dbcp][scxml] Apachecon, North America April 7-9

[Phil Steitz]

I will be presenting on the newly-released 2.x versions of Commons
Pool and DBCP next month at Apachecon, North America in Denver [1].

Ate Douma is also giving a talk on [scxml].

Come join us!

Register soon, as prices go up on March 14th.

Phil

[1] http://na.apachecon.com/.


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCEMENT] Apache Commons Pool 2.1 released

[Phil Steitz]

The Apache Commons Team is pleased to announce the release of Apache Commons 
Pool 2.1.

The Apache Commons Pool open source software library provides an object-pooling 
API and a number of object pool implementations.

No client code changes are required to migrate from version 2.0 to 2.1.  Users 
of version 1.x should consult the migration guide on the Commons Pool web site.

Source and binary distributions are available for download from the Apache 
Commons download site:
  http://commons.apache.org/proper/commons-pool/download_pool.cgi

When downloading, please verify signatures using the KEYS file available at the 
above location when downloading the release.

Full details of all the changes in 2.1 can be found in the changelog:
  http://commons.apache.org/proper/commons-pool/changes-report.html

For complete information on Commons Pool, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Commons Pool website:

http://commons.apache.org/proper/commons-pool/

Phil Steitz, on behalf of the Apache Commons community


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[pool] Factory example

[Manuel Irribarra]

  
  
Hi,

 Following the example page, I noted that Factory example for
PooleableObjectFactory is wrong. When you extends
BasePooledObjectFactory?, there only 2 methods required:

+ public ? create()
+ public PooledObject? wrap (? object)

 I guess that create method must created a new object instance,
but... how I must use the wrap method?

 Any one have an example?

-- 
  

  
  Manuel A.
  Irribarra Frex
Ingeniero de
  Desarrollo
Altiuz Soluciones Tecnolgicas de Negocios Ltda.
Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
+56 2 2335 2461
  
  

  
  mirriba...@altiuz.cl
http://www.altiuz.cl
http://www.altiuzreports.com
   
 
  
  

  

  

  
  

  

  

Re: [pool] Factory example

[Phil Steitz]

On 11/29/13, 7:28 AM, Manuel Irribarra wrote:
 Hi,

 Following the example page, I noted that Factory example for
 PooleableObjectFactory is wrong. When you extends
 BasePooledObjectFactory?, there only 2 methods required:

 + public ? create()
 + public PooledObject? wrap (? object)

 I guess that create method must created a new object instance,
 but... ¿how I must use the wrap method?

 Any one have an example?

Yes, create() creates a new object instances.

wrap creates a PooledObject from a newly-created instance.  There is
a DefaultPooledObject implementation provided.  To use that, just use

@Override
 public PooledObjectFoo wrap(Foo foo) {
return new DefaultPooledObjectFoo(foo);
 }
 
Thanks for pointing out the problem with the example page.  It needs to be 
updated to reflect the new API.  It is still using the old 
PoolableObjectFactory, which no longer exists.  I will replace this with a 
working 2.0 example shortly.

Phil



 -- 
 *Manuel A. Irribarra Frex*
 *Ingeniero de Desarrollo*
 Altiuz Soluciones Tecnológicas de Negocios Ltda.
 Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
 +56 2 2335 2461
 mirriba...@altiuz.cl mailto:mirriba...@altiuz.cl
 http://www.altiuz.cl
 http://www.altiuzreports.com  https://www.facebook.com/altiuz
 http://twitter.com/altiuz http://www.linkedin.com/company/altiuz

   



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [pool] Factory example

[Manuel Irribarra]

  
  
Thanks Phil, this work great.

On 29/11/13 13:25, Phil Steitz wrote:


  new DefaultPooledObjectFoo(foo);


-- 
  

  
  Manuel A.
  Irribarra Frex
Ingeniero de
  Desarrollo
Altiuz Soluciones Tecnolgicas de Negocios Ltda.
Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
+56 2 2335 2461
  
  

  
  mirriba...@altiuz.cl
http://www.altiuz.cl
http://www.altiuzreports.com
   
 
  
  

  

  

  
  

  

  

[ANNOUNCE] Apache Commons Pool 2.0 released

[Mark Thomas]

The Apache Commons Team is pleased to announce the release of Apache
Commons Pool 2.0.

The Apache Commons Pool open source software library provides an
object-pooling API and a number of object pool implementations.

Version 2 of Apache Commons Pool contains a completely re-written
pooling implementation compared to the 1.x series. In addition to
significant performance and scalability improvements - particularly
under highly concurrent loads, version 2 includes robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.


Source and binary distributions are available for download from the
Apache Commons download site:
  http://commons.apache.org/proper/commons-pool/download_pool.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.


Version 2.0 is not backwards compatible with earlier releases. There
have been numerous API changes to support new features as well as to
clarify behaviour and improve consistency across the API. Therefore, to
support side-by-side usage of 2.x and earlier versions, the packaging of
version 2.0 has been changed to org.apache.commons.pool2.

Full details of all the changes in 2.0 can be found in the changelog:
  http://commons.apache.org/proper/commons-pool/changes-report.html


For complete information on Commons Pool, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Pool website:

http://commons.apache.org/proper/commons-pool/

Mark Thomas, on behalf of the Apache Commons community

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

RE: [ANNOUNCE] Apache Commons Pool 2.0 released

[Gary Gregory]

Congrats to [pool] on a 2.0 finally seeing the light of day!

Gary

 Original message 
From: Mark Thomas ma...@apache.org 
Date:11/11/2013  10:25  (GMT-05:00) 
To: Commons Users List user@commons.apache.org 
Cc: Commons Developers List d...@commons.apache.org,annou...@apache.org 
Subject: [ANNOUNCE] Apache Commons Pool 2.0 released 

The Apache Commons Team is pleased to announce the release of Apache
Commons Pool 2.0.

The Apache Commons Pool open source software library provides an
object-pooling API and a number of object pool implementations.

Version 2 of Apache Commons Pool contains a completely re-written
pooling implementation compared to the 1.x series. In addition to
significant performance and scalability improvements - particularly
under highly concurrent loads, version 2 includes robust instance
tracking and pool monitoring. Version 2 requires JDK level 1.6 or above.


Source and binary distributions are available for download from the
Apache Commons download site:
  http://commons.apache.org/proper/commons-pool/download_pool.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.


Version 2.0 is not backwards compatible with earlier releases. There
have been numerous API changes to support new features as well as to
clarify behaviour and improve consistency across the API. Therefore, to
support side-by-side usage of 2.x and earlier versions, the packaging of
version 2.0 has been changed to org.apache.commons.pool2.

Full details of all the changes in 2.0 can be found in the changelog:
  http://commons.apache.org/proper/commons-pool/changes-report.html


For complete information on Commons Pool, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Pool website:

http://commons.apache.org/proper/commons-pool/

Mark Thomas, on behalf of the Apache Commons community

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org