[jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ http://issues.apache.org/jira/browse/POOL-75?page=comments#action_12415435 ] Gordon Mohr commented on POOL-75: - Re: (1) I see; it seems it would be sufficient to move the _borrowerQueue.add(Thread.currentThread()); inside the synchronized block. (I believe the idea of thread-fairness is really only sensible with respect to WHEN_EXHAUSTED_BLOCK pools -- in the others, borrowObject() never blocks, so there's never the unfair/barging risk.) Re: (2) This was a straight copy of the superclass code; I see that the superclass has been changed in the SVN tree, so definitely the same fix should apply here. Re: (3) I hadn't considered the evictor; our use case doesn't use it, and I think the usual case where thread fairness is important -- rationing a small number of pool objects among a large number of threads -- may be more likely to use non-expiring pool objects. Looking at evict(), it appears to me that it is indeterminate whether the evictor or a blocking borrower would get the first chance to run after an object is returned -- but also that it doesn't need to be determinate, and any app using eviction is going to be robust about pool objects sometimes expiring an instant before being requested. (That is, my concept of thread fairness is orthogonal to the evictor's actions.) Thanks for considering the patch. Do you want me to make the recommended changes and resubmit? [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]
[jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ http://issues.apache.org/jira/browse/POOL-75?page=comments#action_12415461 ] Sandy McArthur commented on POOL-75: After having slept on it and since thread fairness only makes sense in the WHEN_EXHAUSTED_BLOCK case I think the best plan is to: 1. Patch GenericObjectPool instead of creating a subclass. GOP is a bit of a hair ball but I think adding one more configurable feature is less hairy than exposing more of it's internals to allow subclassing. Personally, I think GOP is really dangerous to extend as use of it in that way wasn't well thought out as it was patched over the years and I don't want to encourage that kind of use as it's so fragile. Also, I don't think the setting use fair queueing feature should be added to the constructors. They are unwieldily enough already and I've fixed few bugs due to the confusing nature of keeping the parameters straight. Just let it be controlled via a setter method, no need to add another constructor that will take 14 parameters, though I do think it should be added to the GOP.Config class. 2. I think all or most all of the thread fairness can be implemented in the WHEN_EXHAUSTED_BLOCK case of the switch statement. This would keep the scope of the changes as narrow as possible. 3. Since the evictor sometimes adds idle objects to the pool, despite it's name, I don't think it should get in line like the other threads as that could slow everything down. If you want to rework the patch then go for it, else I'll eventually get to it before the 2.0 release. [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]
[jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ 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]
[jira] Commented: (POOL-75) [pool] GenericObjectPool not FIFO with respect to borrowing threads
[ http://issues.apache.org/jira/browse/POOL-75?page=comments#action_12415081 ] Gordon Mohr commented on POOL-75: - You didn't like my patch? (See bugzilla; it doesn't depend on util.concurrent.) Even if the subclass itself isn't to be integrated -- it is a little awkward -- if the GenericObjectPool class were a bit more friendly to subclassing (fewer private fields) anyone could drop in the Fair subclass without having to patch GenericObjectPool itself. [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 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]
