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 --- Additional Comments From [EMAIL PROTECTED] 2006-04-16 10:26 --- (In reply to comment #6) First, there is no pool size setting in GenericObjectPool. This bug report is based on the incorrect assumption that there is such a thing. There are maxActive and maxIdle settings but they are not the same thing as the pool size. OK, please tell me then, how can I have the naive pool concept given in Wikipedia with commons pool, i.e. a finite set of initialised objects that can be requested from the pool and be returned to the pool? Concrete, how can commons pool manage a finite pool of 20 LDAP connections? Which pool implementation should I use, so that makeObject() only gets called 20 times and there are only 20 LDAP connections in the pool? -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2006-04-15 22:01 --- First, there is no pool size setting in GenericObjectPool. This bug report is based on the incorrect assumption that there is such a thing. There are maxActive and maxIdle settings but they are not the same thing as the pool size. (In reply to comment #5) 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. Re-read comment #4, with the above statement you've just proven my point. GenericObjectPool has a default maxIdle setting of 8. You'll find your test code seems to work with a maxActive up to and including 7. From 8 and above you'll see the behavior you are incorrectly claiming to be a bug. If you set the maxIdle to a negative value, there will be no limit on the number of idle objects and you'll basically get your desired pool size behavior. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
