[ http://issues.apache.org/jira/browse/POOL-75?page=comments#action_12415087 ]
Sandy McArthur commented on POOL-75: ------------------------------------ While the implementation in the patch (in bugzilla) looks straight forward, I think it has some problems. 1: I think with the _borrowerQueue.add(Thread.currentThread()); out side the sync block you have race that could lead to: 1.a: a pool configured to use WHEN_EXHAUSTED_FAIL to throw a NoSuchElementException when it shouldn't. 1.b: a pool configured to use WHEN_EXHAUSTED_GROW to create a new poolable objects when there are idle objects available. 2. Since if this were to be included in Pool it would mostly likely be included in Pool 2.0 it should pass those unit tests. (To test with these extend TestObjectPool or subclass and implement the makeEmptyPool methods and the suit method.) Currently it fails the TestObjectPool.testPOFBorrowObjectUsages() test as it calls activateObject for an object that was just made via makeObject. This fix is as simple as adding return pair.value; right after the newlyCreated = true; line. 3. How is this supposed to work with the evictor? Is the evictor allowed to preempt the other threads? I think that is what would happen now. > [pool] GenericObjectPool not FIFO with respect to borrowing threads > ------------------------------------------------------------------- > > Key: POOL-75 > URL: http://issues.apache.org/jira/browse/POOL-75 > Project: Commons Pool > Type: Improvement > Versions: Nightly Builds > Environment: Operating System: All > Platform: All > Reporter: Gordon Mohr > Assignee: Sandy McArthur > Priority: Minor > > GenericObjectPool has recently been made FIFO with respect to the managed pool > objects -- however, it is still not FIFO with respect to threads requesting > those objects. Specifically, because standard non-fair Java synchronization > monitors are used, later threads may barge ahead of earlier threads that are > already waiting for a pool object to become available. At its extreme, some > threads can cycle objects through the pool many times while others wait > interminable. > Not every application needs FIFO fairness with respect to threads, and such > fairness implies an overhead, so it need not be the default behavior, but it > would be a valuable option where many threads are sharing a smaller number of > pool objects. > I can submit a FairGenericObjectPool which achieves thread-fairness; it only > requires small changes to GenericObjectPool which allow some subclass > overriding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
