geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [components] - lazy loading...
Date Mon, 11 Aug 2003 15:01:19 GMT
I really like this idea. Berin seems to think that it's eminantly 
doable, Jason sounds like he needs to be convinced.

If this is already provided as part of Avalon, or Avalon-esque systems, 
then perhaps this is worth investigating in more detail? Could Berin 
provide this?

It might not be doable using the current JMX interceptor stack, but if 
it can be done using another mechanism (and demonstrably so) then 
perhaps that's a good reason to look at using a different mechanism.

Alex.

On Monday, Aug 11, 2003, at 15:32 Europe/London, Berin Loritsch wrote:

> Jason Dillon wrote:
>
>>> Imagine that rather than having a set number of configurations which 
>>> all load every service at startup, Geronimo could load just the 
>>> components needed to provide the services required by your 
>>> deployables...
>> I like the concept, but I am not sure how easy this will be to 
>> actually implement.  To make something like this work, we would need 
>> to load configuration metadata for everything on boot, so that we 
>> knew what components we had to work with.  I mean, how else would the 
>> component container know which components it had to work with to 
>> start the services required by the deployable?
>
> It's not that hard, really.  I have done it a couple of times for the
> containers at Avalon.
>
>
>> Sounds like a lot of complex magic inside to achieve lazy loading.
>
> There is nothing written in stone that the central container-container
> should require JNDI.  There are some very simple approaches that does 
> not
> require complex logic to achieve on-demand loading.
>
>>> If we could lazily load services as required, startup time would be 
>>> greatly reduced, footprint as well, and the distributions complexity 
>>> too - since we could just ship everything and only what was needed 
>>> would be used.
>> Initial startup time may be reduced, but if an app requires JNDI, 
>> JavaMail or whatever, then the time initialize these will not change, 
>> we have just moved where that time is spent.
>
> Another approach to minimize startup time that also works quite well
> is asynchronous component management.  I have designed the Avalon 
> Fortress
> container to load components in a controlled set of background threads 
> so
> that the initialization load would be spread among all available 
> processors.
> In fact, it adapts the number of threads to the number of processors 
> available.
>
> That said, as long as you can guarantee that any requested instance is
> available and fully initialized on first use, then all is well.  The 
> approach
> uses a library inspired by SEDA principles (Avalon Event) that 
> provides a
> CommandManager.  The CommandManager executes Command Events from an 
> event
> queue.  The commands get executed in order, and it pulls the 
> initialization
> logic and overall component management logic away from the critical 
> path.
>
> The advantage of the approach over regular inline initialization and 
> component
> management is at least 5:1, and in some cases 15:1.  Anything is 
> doable.
>
>
>> I do like the concept, but I think this may not be feasible in the 
>> short-term... though it would depend a lot on what we use for 
>> component management I would say.
>
> It does.  Most of these things are already available with some 
> containers.
>
> The advantage of lazy loading is that you can make sure you aren't 
> loading
> what you don't need ahead of time--reducing the memory footprint, which
> has an impact on scalability (larger margin before GCs are necessary).
>
> -- 
>
> "They that give up essential liberty to obtain a little temporary 
> safety
>  deserve neither liberty nor safety."
>                 - Benjamin Franklin
>


Mime
View raw message