Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F37B6E0.6090409@apache.org>
Date: Mon, 11 Aug 2003 11:31:44 -0400
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: [components] - lazy loading...
References: <GHEHKNNAODAPCLJONCCDCEDECPAA.jeremy@coredevelopers.net>
In-Reply-To: <GHEHKNNAODAPCLJONCCDCEDECPAA.jeremy@coredevelopers.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeremy Boynes wrote:

> In repsonse to Berin Loritsch:
> 
> Fast startup is primarily a benefit for developers and less of an issue in
> production environments. Production configs need scalability and stability,
> and will typically use all the services they ultimately need from the
> outset.
> 
> I think a reasonable balance between the two is to aggressively load just
> what is needed for any deployment at deployment time.
> 
> This handles the development case, where only the necessary services get
> loaded on startup, and the service mix stays constant as applications are
> redeployed by the developer.
> 
> It also handles the production case, in that all services needed are loaded
> together giving a deterministic failure point, but only the ones needed by
> the apps are actually loaded conserving system resources.
> 
> The loading pricipals you described would work well, its just that
> "first-use" becomes deployment time rather than run time.
> 
> The caveat I would throw in is that if the system is online, I like have the
> option of either dedicating one thread to loading a new application (leaving
> the other threads to service requests) or of dedicating all threads to
> redeploying an existing application (to reduce outage time).

As it is currently written there are three component instantation options:

* Inline--component is always initialized in the critical path.
* Asynchronous--component is always initialized in a set of background threads
                 (no need to restrict to one or multiple) The command manager is
                 configurable to use X number of threads per processor.
* On demand--component is only initialized when looked up.

As a safety measure, all components can opperate with "On demand" semantics.
That way we can avoid any race conditions with the Asynchronous model or the
mix of asynchronous and inline components.  If a component is requested before
it has been initialized, the container is smart enough to initialize it on
demand and protect against double-initialization.

So if you want to option to force "Inline" you have it.  If you want the option
to put some components with asynchronous initialization and some with on demand,
then you have it.  No additional coding necessary.

Also, the asynchronous command manager really helps in controlling the container
and other components without hurting the critical path.  If you need to
periodically notify certain components of a particular event, the CommandManager
supports both delayed and repeated commands.  Using this approach, we can keep
our pool of threads free until we really need them.  The monitoring command will
be called as necessary and invoked with any free thread.  It is a powerful way
to go.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin