Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41511D2D.1090002@indriyas.net>
Date: Wed, 22 Sep 2004 08:35:25 +0200
From: Stephan <stephan@indriyas.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: commons-dev@jakarta.apache.org
Subject: (Pool) Pools should be self tuning
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I've recently discovered the package "Commons Pool" and I've played with 
  GenericObjectPool. I'm attracted by all the options you can set to 
customize the behavior of the pool but after a while I started to ask 
myself. "Am I choosing sensible settings? Should I do this or should I 
do that?"

Of course the answer depends of the usage pattern of the pool, and this 
is something that might change over time. Conclusion: I will probably 
never know what's the useage patern of a pool and I don't want to guess it.

To solve this problem, in my opinion, the pool should be self tunning. 
Just like the Evictor thread (which is just a trigger), another thread 
would wakeup at regular intervals and gather statistical data and 
analyse it. As a result action would be taken (like changing the values 
of the pool settings) to adapt the pool to the usage pattern.

How you you go about monitoring the usage pattern of a pool?
The only ideas I have right now is using a moving average of the active 
connections and may be remembering this average throught the day so that 
  the pool that anticipate usage. Imagine an automatic process that uses 
the pool once a day at 1:00 and borrows 1000 objects from the pool in a 
few seconds: The pool could anticipate this regular usage and create 
more objects in the pool.

I'm not very good at statistics and I hope that some of you are and 
could explain how statistics could help in this task.

This self tuning thing could be a more general problem and find other 
applications in other pagakges.


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