commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <>
Subject [jira] [Commented] (POOL-232) GOP: borrowObject() & returnObject() are still not FIFO
Date Tue, 23 Jul 2013 22:12:49 GMT


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
> GOP: borrowObject() & returnObject() are still not FIFO
> -------------------------------------------------------
>                 Key: POOL-232
>                 URL:
>             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:

View raw message