> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 9:26 PM > > > Paulo Gaspar wrote: > > > Here we go again... > > =:o) > >>My solution has a formal "CommandManager" that allows any Component to > >>drop a Command into it's queue and have it executed when the processing > >>thread is ready. This allows 1 or maybe even 2 threads handle all > >>asynchronous management for all pools. > >> > > > > My ThreadPool just accepts a Runner or Action. I thought I got it from > > Avalon too. I am sure it was from somewhere in Jakarta (Commons?). > > > > Isn't that enough? > > > What about growing the initial size of the pool asynchronously so that > the system can continue initializing in the mean time. There will always > be odd jobs to do (Is that connection still good?) in the barckground, > and it is easier to implement if there is one common interface to do it > all. My confusion. Only later in my text did I correct ThreadPool to Scheduler!
I have an inner Runnable on the pool that is register with the Scheduler and performs such cleanup operations. > >>By adding the Concept of a PoolManager, we would have one manager for > >>n pools. That manager houses all the logic for the managed pools. > >> > > > > What does the PoolManager extra besides the threading stuff? > > > It also manages the adaptive pool size depending on Time of Day and > Day of Week, or whatever algorithm you want to use. > > It has the ability to derive the optimal pool size based on historical > information--if the manager is so inclined. Ok, you have several strategies that you might apply to a pool. I even start seeing some usefulness on being able to register several "PoolManagers" per Pool. Like, I want this pool with: - Check 3 connections for old age each 5'; - Check 2 Connections for validity each 2'; - Close all connections at 4:00 AM; - Put minimum connections at 50 just before rush hour; - Cut down minimum connections after rush hour. See? Piece by piece, maybe with the first 2 a bit enforced. You got me a nice idea! > >>>The interesting new bit at Avalon is already the ability to > >>>serialize back to disk the new/adapted configuration of such > >>>adaptive components. > >>>=:o) > >>> > >> > >>It's not implemented yet, but it will be. > >> > > > > Doesn't the "DefaultConfigurationSerializer" work already? > > > Yes (still needs work for namespaced configuration objects). There > is no formal framework for the bidirectional management of the > Configuration file yet. For simple stuff it could be already very helpful. 2 way tools are dangerous. Ask Borland!!! (Their first development tool with 2 way tools got very late. Rumors say it was the 2 way bit. (Was it DBase IV?)) > >>>The most interesting bit of dynamic management, for me, is > >>>interaction trough some user interface tool. Looking at metrics, > >>>changing parameters on the run and saving the configuration > >>>with beautiful and easy to use tools... what a nice dream! > >>>=:oD > >>> > >> > >>That is what Profile (Avalon instrumentation) will allow. I proposed > >>to JMeter to have their metering abilities expanded, but for now > >>they have not responded to my message. I will repost when I have > >>an implementation of Profile in place. > >> > >>Another piece would be the GUI configuration. > >> > > > > Isn't Peter working on some JMX based tool already? > > > I think so... But that is for Phoenix. The core API does not use JMX. If it is somewhere, it will get used and copied/ported somewhere else! =;o) Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
