geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: [components] - lazy loading...
Date Sat, 09 Aug 2003 14:08:28 GMT
Aaron Mulder wrote:

>	If you deploy a typical EAR, this won't save you a whole lot,
>because the server itself will start darn fast, then try to deploy an app,
>which loads the deployer, the web & EJB containers, DB pools, JNDI,
>transactions, security, web connectors, "EJB connectors", and so on -- the
>majority of available services.  You may save the effort of JMS and J2CA,
>depending on the app, but it's not the huge advantage that it initially
>sounds like.
not every ear contains both war and ejb.jar
there are many other services that make up an enterprise strength AppServer
There are many dependencies between them
I expect there to be many more in Geronimo
Different people will use Geronimo for very different things


Your solution is similar to mine. You have just shifted the 
responsibilty for lazy loading the bulk of a service to the service 
itself, rather than the underlying container.

Seeing as a container's job is to isolate and abstract away commonality 
such as this, I maintain that it's proper place is in here where the 
code only need be written once and will mature quicker. Since the 
container is also in charge of service lifecycle and interservice 
dependencies, it can make optimisations that the service cannot. (Of 
course the service has advantages over the container (self-knowledge), 
but could take advantage of them as well).

Of course if you wish to override it in particular services, I wouldn't 
see a problem with that. You would simply register them as mandatory and 
let them take control of their own laziness.


>	I think we'd get more mileage out of aggressively ensuring that
>components start up quickly.  You'd get a lot more (let's say) by ensuring
>that all 20 components together start up in under a second that you would
>by not starting the small number of them that an application required.
>On Sat, 9 Aug 2003, Jules Gosnell wrote:
>>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*. 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...
>>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 :-)
>>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 
>>>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.

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message