[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-user
Subject:    Re: [pool] Re: Commons Pooling request queue algorithm?
From:       Phil Steitz <phil.steitz () gmail ! com>
Date:       2013-09-21 19:52:47
Message-ID: 523DF90F.6080609 () gmail ! com
[Download RAW message or body]

On 9/20/13 10:42 AM, Programmer wrote:
> Thanks Phil.
> 
> I was interested to know about the 'fairness' of the connection distribution
> from the client perspective. :)

OK.  Sorry I did not get the question at first.  Let me explain a
little better how the 1.5.x / 1.6 servicing algorithm works, so you
understand what I mean by "mostly" fair.  When borrowObject requests
arrive, they are assigned "latches" that go onto an "allocation
queue."  The queue is worked in latch-creation order (so
FIFO/fair).  "Working" the queue consists of allocating returned
objects to latches and/or issuing object creation permits to
latches.  When the pool is configured to wait when exhausted,
waiting threads tell their latches to wait and the latches get
notified when they have been assigned returned objects or when they
have been given object creation permits.  Creation permits get
issued when the pool is warming up or when due to maxIdle config or
validation failures the pool destroys objects, creating capacity for
new ones <side-rant>This is expensive and defeats pooling benefit,
so config / environment should be tuned to avoid too much of it
</side-rant>.  Threads holding latches that get creation permits
invoke - so have to wait for - the factory methods to create the
instances, so it is possible that "lucky" threads that get to
perform this duty end up completing after successors to them have
been served, because returns may happen while they are waiting on
the factory makeObject method to complete.

Phil
> 
> 
> 
> --
> View this message in context: \
> http://apache-commons.680414.n4.nabble.com/Commons-Pooling-request-queue-algorithm-tp4653914p4653919.html
>  Sent from the Commons - User mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]