On 5/11/11 3:30 AM, Mark Thomas wrote: > On 11/05/2011 03:26, Phil Steitz wrote: >> On 5/10/11 8:48 AM, ma...@apache.org wrote: >>> Author: markt >>> Date: Tue May 10 15:48:22 2011 >>> New Revision: 1101516 >>> >>> URL: http://svn.apache.org/viewvc?rev=1101516&view=rev >>> Log: >>> Move to using LinkedBlockingDeque for the queue of idle objects. >> Definitely simpler, cleaner code, but seems there will be no easy >> way to enable fairness and some badly "unfair" stuff can happen when >> clients get instances under maintenance. In theory, an unlucky >> client could wait forever. Do we have any data on how "unfair" >> LinkedBlockingDeque can be? > No. I suspect it will be as bad as the old non-fair DBCP implementation. > >> ArrayBlockingQueue is an alternative >> that does support fairness; but then I guess we lose LIFO/FIFO >> control and probably performance. > Losing LIFO/FIFO is a non-starter in my view. > >> Any ideas how we could get fairness, or at least some control over fairness >> to work? > My best ideas so far was to copy jdbc-pool's approach and wrap the Deque > and provide fair locking in the wrapper. > >> Another >> thing to think about is whether clients are better off waiting for >> the state change on instances under maintenance than getting back in >> line for the next available instance. (I now see the fairness TODO >> in TestGOP :) > It depends how busy the pool is. If there are other idle instances, > getting back in line will be fine. If the pool is exhausted, better to > wait for the instance currently being tested.
Also depends on which kind of maintenance is happening when the client arrives (validation or expiry testing) and how fast validation is. > On reflection, it should be possible to allow borrowing to over-ride an > in-progress eviction test. That should always be the fastest solution. I thought about that too; but it would be tricky to do. Depends on at what point the borrower arrives during the maintenance visit. If the instance is actually in process of being destroyed or tested, would be dicey to try to break in. Have to be very careful with the locks if we implement this. Phil > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
