geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: [components] - lazy loading...
Date Sat, 09 Aug 2003 09:51:15 GMT
Stephen McConnell 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? 
>
>
>
>
> 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. 

see my point about development vs production mode - you just flick a 
switch which forces everything to be loaded proactively (c.f. 
precompiling JSPs instead of shipping JSP src to production). You do 
this periodiacally during your dev cycle to ensure all is OK.

Of course, this would not test the lazy loading framework itself, but 
would test everything else.

Jules

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


-- 
/*************************************
 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * http://www.coredevelopers.net
 *************************************/



Mime
View raw message