avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Wed, 09 Jan 2002 20:26:20 GMT
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.


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



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



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




-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message