[
https://issues.apache.org/jira/browse/POOL-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717694#comment-13717694
]
Mark Thomas commented on POOL-232:
----------------------------------
The synchronized blocks in question are:
- the one around the call to _allocationQueue.add(latch) in borrowObject()
- the one in addObjectToPool.
I suspect POOL-75 was marked as resolved as the sync blocks were previously
significantly larger and led to non-fair allocation at very low levels of load.
The current implementation should be fair in nearly all circumstances. You
might see some unfairness under extremely heavy load. There is a unit test for
fairness: TestGenericObjectPool#testBorrowObjectFairness().
The issue with ReentrantLock is that with fairness enabled, throughput is
likely to suffer. The higher the load, the more likely throughput is to suffer.
It is possible that enabling fairness results in worse performance for all
threads than the current implementation.
One option would be to switch to ReentrantLock with fairness disabled by
default with an option to enable it. (Although I hate the idea of having to add
yet another constructor that this would require.)
Personally, I would like to see a patch to
TestGenericObjectPool#testBorrowObjectFairness() that demonstrates that the
current implementation is not fair for a given load. If necessary to
demonstrate the issue, we can run the test in people.a.o where we have 48 cores
to work with.
> GOP: borrowObject() & returnObject() are still not FIFO
> -------------------------------------------------------
>
> Key: POOL-232
> URL: https://issues.apache.org/jira/browse/POOL-232
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.6
> Reporter: Deepak
>
> Latest Pool API (1.6) is still not implemented the fairness policy, because
> of the usage of the synchronized construct in the two important
> borrowObject() & returnObject() APIs
> If you have very high no. of clients threads, trying to invoke either
> borrowObject() & returnObject() APIs, then their order will not be respected
> because synchronized keyword doesn't guarantee the fairness. ReentrantLock
> could be used in both the APIs in order to have the fairness policy
> implemented.
> Though in the past, someone raised the exact same issue (POOL-75), but don't
> really understand that how it is fixed when issue seems to be still present.
> I am from telecom industry, and I use this library in the reall time call
> flow, so for me fairness is very important.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
