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 08:50:06 GMT

initially you could just do this at low granularity, i.e. deployer, 
level - only load a deployer when you find something that you need it to 
deploy, although once it is loaded you keep it, rather than unloading it 
if e.g. the webapp that you loaded it for is undeployed.

more inline...

Jules Gosnell wrote:

> Jason,
>
> I followed pretty much the same though path as you have just outlined 
> after posting - then I hung in there and thought some more :-)
>
> Yes it makes things more complex, however:
>
> In development, which is where we have already proven you need to 
> capture hearts and minds first, startup time and footprint are 
> important. You would be amazed how many people I have come across in 
> my JBoss dealings who still have to do a lot of cold deployment... 
> Besides as Geronimo developers, therefore the people who will be 
> restarting it most, this would speed our own development cycle.
>
> J2EE decomposes nicely into a bunch of APIs javax.xxx.*. We just need 
> a persistant registration service. The first time you run up Geronimo, 
> all services start, declaring that e.g. they implement javax.naming or 
> javax.servlet etc... (package granularity should be enough). Deployers 
> also register their interest in e.g. WebContainer:war etc...
>
> These deps are saved away, and next time you start Geronimo, put to 
> good use - the dependency tree is shaken out and only services 
> required are loaded. This behaviour could be switchable, to load 
> lazily in development and proactively in production.
>
> I was thinking that the ClassLoader could do something similar. 
> Instead of sitting there watching hundreds of jars being loaded from 
> server/x/lib, it could load the index that it saved from the last run 
> and then load these classes lazily as and when required. Further 
> startup time speedups... 

rather than being 'loaded' from server/x/lib, I should have said that 
the jars are being reindexed for the nth time by the classloader, so 
that it knows where to lazily load a class from when required. I am just 
suggesting hanging on to that index between runs, so we don't have to 
build it again on every restart...

I expect a fully loaded Geronimo to become HUGE :-), anything we can do 
to mitigate bloat in a running image would be good. Making static 
decisions about what is needed has been done. We should be considering a 
dynamic mechanism...

OK - I'll shut up now :-)

Jules

>
>
> If you upgrade or add new services, jars, their presence would 
> invalidate the relevant part of the cached dependency tree or index.
>
> Complex, yes, innovative and possibly valuable - yes.
>
> I don't want something like this to get in the way of getting a server 
> out of the door ASAP, but I'd like it to be considered if anyone 
> starts working, out on  branch, on the ultimate plug-in component 
> system for Geronimo services...
>
>
> What do you say :-)
>
>
> Jules
>
>
> 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?
>>
>>
>>> 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.
>>
>>
>>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> --jason
>>
>
>


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



Mime
View raw message