geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [components] - lazy loading...
Date Sat, 09 Aug 2003 09:39:58 GMT


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? 



Within the Avalon Merlin system this is managed using a meta-data model 
that enables the construction of component type managers.  The manager 
(an Appliance in Merlin terminology) represents a one-to-one mapping 
with a identifiable deployment scenario.  The manager is also 
responsible for instance creation - so its here that you can get the 
benefits of lazy activation.


>
>
>
>> e.g. you are doing web development, so when you start Geronimo it 
>> just loads the webcontainer component and deploys your webapp. You 
>> webapp decides to load a javax.naming class so the JNDI service is 
>> brought on  line, it loads a javax.mail class and looks up a mail 
>> service in JNDI - the mail service is brought up... etc
>
>
> Sounds like a lot of complex magic inside to achieve lazy loading.



My guess is that you would end up with a set of notions covering type 
descriptors, deployment directives, a containment model, and management 
services.  These facilities will be needed anyway - so in principal the 
notion of lazy activation should be rather trivial if you have the 
infrastructure in place.

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


There is the other-side of the lazy activation equation - namely 
aggressive disposal.  Lazy activation is basically making sure that a 
component that implements a service is not introduced until it is 
actually needed.  Aggressive disposal is about getting rid of service 
implementations that are no longer needed.

>
>
> Personally I do not believe that this buys us all that much.  While 
> lazy loading may (or may not) be nice during development, in a 
> production environment I would rather have a slow startup where all of 
> my components are initialized and connected. 


Naturally - putting lazy activation and aggressive disposal together 
makes for an interesting combination in a production environment.

>
>
> On the other hand, if the component container had knowledge of the 
> available components/services, then was asked to deploy a web-app, 
> which requires a web-container, JNDI, whatever, then then container 
> could initialize and start these components automatically with out 
> having to explicitly list them as components to be started when the 
> server comes up. 


Just a note here - using this approach (sucking in automatically) can be 
problamatic because you can easily end up with an implementation which 
effectively delays deployment errors until a service is requested.  One 
way of minimizing this to to do a complete validation of the feasibility 
of a potential deployment scenario ahead of deployment.  This can get 
really interesting because you can introduce tools that simulate 
deployment at build time.

>
>
> I think to make something like this work it would have to be done at a 
> component connection/dependency level and will depend much on the 
> component container we use or write.


Absolutely.

Stephen.

>
> --jason
>
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




Mime
View raw message