You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2006/04/15 12:05:31 UTC

DO NOT REPLY [Bug 39314] - [pool] Pool grows beyond poolsize with WHEN_EXHAUSTED_BLOCK

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39314>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39314


juergen@jwi.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|[pool] Pool grows beyond    |[pool] Pool grows beyond
                   |MaxActive with              |poolsize with
                   |WHEN_EXHAUSTED_BLOCK        |WHEN_EXHAUSTED_BLOCK




------- Additional Comments From juergen@jwi.de  2006-04-15 10:05 -------
(In reply to comment #4)

I should reformulate to "makeObject() is called more than poolsize times."

As I understand the concept of pool (which is consistent with
http://en.wikipedia.org/wiki/Object_pool), a non-growing pool keeps a certain
limited number of objects.

In my use case, I want to keep in the pool n open connections to the LDAP
server, after all n connections are opened within makeObject(), these n
connections from the pool should be used and none more. 

So, makeObject() should not be called more than poolsize times
(WHEN_EXHAUSTED_BLOCK). But with GenericObjectPool it gets called forever (and
my LDAP server runs out of threads).

Strange thing is, if poolsize in the example code is 3 the test runs fine, but
with a poolsize of 20 the pool grows forever.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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