commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom <t...@tbee.org>
Subject Re: pool: stack, cycle and eviction
Date Tue, 30 May 2006 19:08:56 GMT

> It seems to me you are worrying about pool's performance under a light
> load when what matters is pool's performance under heavy load.
Agreed and we do use the pools under heavy load. The contrived scenario 
was to show, using graspable numbers, that because of the cyclic nature 
the actual pool size is not determined by the real load on the pool, but 
the duration of the eviction thread. The scenario shows that even though 
the load is only 1, it maintains a size of 6. The example can be 
upscaled by a 1000 but IMHO still holds: if a pool due to a peak has 
sized to, say, 10000, but normally 20 process each obtain one object 50 
times within the eviction time slot (which can be 5 seconds), 1000 
objects will remain in the pool instead of the for the load required 20. 
In this case a overhead of 98%

I do not mean to insult anyone; it was a scenario I stumbled upon when 
discussing pooling mechanism with my system admin, I just am trying to 
confirm if this is real or if I am mistaken. Using a stack (LIFO) with 
an eviction thread would clean up a pool in these scenarios.


> Personally I don't care if my app isn't perfectly efficient when
> almost nobody is using it but is still capable of handling a full
> onslaught of users during peak load times. Pool is pretty good for
> most people's pooling problems but sure there are gonna be situations
> that would benefit from less generic pooling implementations.

I think stack is a generic implementation (especially since GOP is 
implemented as a stack in 1.2 ;-) )


> Under heavy load a FIFO (queue or cyclic) pool does a better job of
> distributing load. Also in the case of a validating pool being large
> because of a previous peak load a FIFO pool will do a better job self
> managing it's size if idle objects time out before being reused.
On the first account I agree. However if the pool is used to provide 
multiple connections to the same resource, load balancing is not the 
issue. Or if the resource is uniquely allocated while an object is 
reserved, it is not either (once the object is returned to the pool, the 
resource is fully available again).

On the second account I believe my scenario still needs disproving.


>
> Using an evictor validates idle objects can cause a deadlock. 

Since the sequence of objects in the stack is random, I believe it is 
not actually necessary to remove the actual stale objects, only the 
number of stale objects. If the evictor uses the same access as a 
regular client, I do not see why it would deadlock. (I understand your 
locking explanation.) Again at the risk of insulting people: if the pool 
eviction thread uses a two stage approach:
1) decide how many objects need to be evicted
2) using the regular client call and borrow the determined number of 
objects from the pool, but then use an inside call to destroy the object

I think the locking will not be an issue or am I mistaken?


> Probably because no one has submitted an implementation nor have any
> commiters felt there was the demand to spend time on it.
That would be my trigger then, if not for:

>
> That said, the unreleased pool 2.0, currently in the trunk, has a new
> pool dubbed the composite pool which can be configured to behave as a
> LIFO (stack) and has an idle evictor.

Which means that I will not do double work. Any estimate on the release 
date?

But I might have an addition to the pooling logic: I created a 
ObjectPoolWrapper to get rid of those nasty checked exceptions (yes, 
each his own preference) and used that to add a "shutdown" mode. 
Shutdown is a kind of delayed close: when in shutdown the pool does not 
allow borrowing new objects, but does accept returning of objects (and 
destroys them immediately) until all active objects have been returned 
and then the pool closes.

Tom


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


Mime
View raw message