commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@apache.org>
Subject Re: [GenericObjectPool] minIdle and maxIdle
Date Thu, 24 Aug 2006 03:18:21 GMT
Sorry for not replying sooner, just got back from vacation.

First, generally min/max values are applied when a poolable object is
borrowed from the pool or returned to the pool.

On 8/17/06, commons@nemesi.co.uk <commons@nemesi.co.uk> wrote:
> Hi Everyone,
>
> first post in this list... I just need a clarification regarding the minIdle
> and maxIdle fields for the GenericObjectPool class. I am using this class,
> together with PoolableObjectFactory, to implement a Connection Pool for a DB
> for which I can not use the standard JNDI/DataSource pooling mechanism and I
> simply need a clarification on the correct usage of the maxIdle and minIdle
> class fields.
>
> 1) maxIdle will set the maximum number of idle objects (in my case db
> connections) that can sit idle in the pool. This means that if I always want
> to have at least 5 "live" connections ready to listen to requests then I will
> set maxIdle = 5. Is this correct? If not, could you please explain why and
> what I should do to implemente this mechanism?

maxIdle is an upper bound. Think of it as: "I want no more than X idle
poolable objects at any one time so I'll set maxIdle to X."

> 2) minIdle... the doc says "The default minimum number of "sleeping" instances
> in the pool before before the evictor thread (if active) spawns new objects".
> I want the evictor thread to run everytime there are more than 5 (maxIdle?)
> idle connections in my pool. To which value should I then set minIdle to? 1?
> or 6 (5 + 1)? or something else?

The evictor thread runs at intervals, not when criteria are triggered.
When it does run, it tries to enforce that criteria.

A minIdle of 5 and maxIdle of 10 would tell the pool to make a best
effort to keep the number of idle (sleeping) poolable objects between
5 and 10.

> My confusion is actually caused by the definition of the
> DEFAULT_SOFT_MIN_EVICTABLE_IDLE_TIME_MILLIS that is the "time an object may
> sit idle in the pool before it is eligable for eviction by the idle object
> evictor (if any), with the extra condition that at least "minIdle" amount of
> object remain in the pool"...
>
> I would have expected this to say "...with the extra condition that at least
> "MAXIDLE" amount of object remain in the pool...

I think you're confusing minIdle and maxIdle. They are just boundaries
in a range.

-- 
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

---------------------------------------------------------------------
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