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?
It's not that hard, really. I have done it a couple of times for the
containers at Avalon.
Sounds like a lot of complex magic inside to achieve lazy loading.
There is nothing written in stone that the central container-container
should require JNDI. There are some very simple approaches that does not
require complex logic to achieve on-demand 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.
Another approach to minimize startup time that also works quite well
is asynchronous component management. I have designed the Avalon Fortress
container to load components in a controlled set of background threads so
that the initialization load would be spread among all available processors.
In fact, it adapts the number of threads to the number of processors available.
That said, as long as you can guarantee that any requested instance is
available and fully initialized on first use, then all is well. The approach
uses a library inspired by SEDA principles (Avalon Event) that provides a
CommandManager. The CommandManager executes Command Events from an event
queue. The commands get executed in order, and it pulls the initialization
logic and overall component management logic away from the critical path.
The advantage of the approach over regular inline initialization and component
management is at least 5:1, and in some cases 15:1. Anything is doable.
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.
It does. Most of these things are already available with some containers.
The advantage of lazy loading is that you can make sure you aren't loading
what you don't need ahead of time--reducing the memory footprint, which
has an impact on scalability (larger margin before GCs are necessary).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
