geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: [components] - lazy loading...
Date Sat, 09 Aug 2003 13:58:30 GMT
	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.

	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:
> 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*. 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 :-)
> 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
> >

View raw message