james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [Fwd: Re: Dynamic Reconfiguration]
Date Wed, 02 Jul 2003 09:20:17 GMT
Stephen McConnell wrote:

> Steve Brewin wrote:
> >Steve,
> >
> >
> >
> >>While the subject of this message is about re-configuration, I think
> >>that there is an argument for looking at the requirements
> in-terms of
> >>re-deployment.
> >>
> >>
> >> |---------- deployment --------------------->|
> >> |                                            |
> >> |                      |<----- suspension ---|
> >> |                      |                     |
> >> |<-- decommissioning --|
> >> |                      |---- resumption ---->|
> >> |                                            |
> >> |                                            |
> >> |<-------------decommissioning --------------|
> >>
> >>
> >>In the above diagram, "deployment" covers the instantiation and
> >>lifecycle processing of a component by a container.  The act of
> >>"suspension" is to place the component in a volatile state
> >>during which the state provided to it by the container during
> >>the prior deployment cycle is subject to change.  An act of
> >>"resumption" is the process of taking a component from a
> >>volatile state to a stable deployed state, and finally, the act
> >>of "decommissioning" covers the shutdown stages leading
> >>to component disposal.
> >>
> >>
> >
> >As Avalon already defines these phases -
> >http://avalon.apache.org/framework/reference-the-lifecycle.ht
> ml - this seems
> >an entirely sensible approach.
> >
> Going from the specification we have:
>   Recontextualize
>   Recomposable/Reserviceable
>   Reparameterizable
>   Reconfigurable
> These interface do two things:
>   a) act as marker interfaces that signal to a container
>      that a component can handle lifecycle reprocessing
>   b) provides the operation through which a component
>      receives artifacts from the container
> Generally speaking, Avalon is trying to move away from marker
> interfaces
> as they tend to tie implementation semantics into the interface.  A
> better approach is to declare the mutable nature of an
> supplied artifact
> inside meta info (but this is more an A5 subject).

James would have to play by whatever rules the container imposes.

> >It is important that we have control over the order that
> components are
> >suspended and resumed.
> >
> Umm, there is a very important question here - who is "we"?
> A container
> is going "control" the sequencing of component suspension and
> resumption.  In the James case this is interesting because below the
> macro level Avalon components (handled by an Avalon
> container), you have
> multiple mailet instances.  The "James" component in this context is
> acting as a container of these instances, and as such, the James
> component has rather a lot of work to do during a suspension
> re-deployment cycle (equivalent to a classic Avalon container but
> focussed on the mailet implementation classes and instances).


> >For instance, we would want to stop injecting mail
> >into the mailet chain and have the mailet chain complete the
> processing of
> >currently injected mail prior to suspending. The reverse
> during resumption.
> >I don't see anything in Avalon that enables such
> dependencies to be defined,
> >but I'm no expert.
> >
> The Mailet API defines the services that a mailet instance provides.
> The James component is responsible for deployment and
> decommissioning of
> mailet implementation scenarios (mailet class + config +
> context, etc).
> If there is a formal component model for a mailet
> implementation, then
> James can do equivalent management of mailets using an embedded
> container.  Avalon project content in this area is emerging - in
> particular the area of composite containment is rather active.
> What are the principals/ideas used inside James for things
> like mailet
> deployment?  Are mailets implementations potentially
> suspedable/resumable?

You are absolutely correct. The Mailet environment provides a mailet
container in which mailets run. Therefore, the mailet container must be
modified to implement the notion of suspendable/resumable. Suspend/resume
events would need propogating to every mailet instance. The issues to be
solved are essentially the same as for components running in an Avalon

Thinking about it, as James, including Mailets currently shuts down cleanly,
I guess there must be some kind of sequence imposed already. If this is the
case, using the same logic ought to enable a default implementation where
suspend == destroy and resume == init. But I did say <ought>. I'll take a

> >>In this picture the open question is the semantic
> applicable during a
> >>"resumption" phase.  It is reasonable to assume that context
> >>entries are immutable?
> >>
> >>
> >
> >Yes. For components that do not support the suspend/resume
> this would be the
> >default. For components that do support suspend/resume I
> think that this
> >should also be the default. Supporting suspend/resume is saying the
> >component can be suspended and resumed. Declaring context
> entries as mutable
> >is saying that the component supports changing them when in
> the suspended
> >state.
> >
> >Is it a requirement that all components in the server must support
> >suspend/resume in order for the server instance to support
> it? If not, what
> >we could end up with non-suspended components trying to talk
> suspended ones.
> >Not good!
> >
> If component A is suspended, and component B is dependent on
> A but B is
> not suspendable, the container has to decommission B (i.e. take the
> component instance B out of existence - which includes
> decommissioning
> of all components are dependent on or part of B).  This is
> not totally
> hard-and-fast because different containers can use different
> tricks via
> proxies to fake a suspension.  I.e.  if B were allowed to
> continue and
> if it made an invocation against A, the invocation could be
> intercepted
> and stalled within a proxy pending the resumption of A.
> >
> >Maybe we have to add a default implementation of
> suspend/resume for all
> >components, where suspend invokes destroy() and resume
> invokes init().
> >
> This should be a container concern - nothing needed on the
> component.
> There a lots of things a container can do that don't require any
> additions on a component (although I admit that non of this is not
> terribly simple as far as container implementation overhead
> is concerned).

Agreed. My use of the term "we" is woolly. I was indeed thinking of the
> >Unfortunatley, there is a high chance of components that
> (incorrectly) do
> >not cleanly release resources in destroy() which were
> acquired during init()
> >failing.
> >
> >
> This is another area where container implementations can do
> things for
> you. If a component deployment fails - the container can
> unwind things
> such that it really does not matter what the component thinks it has
> references to.  For example, the component thinks it has a
> reference to
> another component when in fact all it has is a reference to a
> proxy, and
> the container can take care of proxy disposal independently of the
> component.
> >>One of the things that can be done to make the above scenario more
> >>manageable is to mark state that is supplied to a component by a
> >>container as immutable.  For example, it is possible to imagine a
> >>component type declaring (as part of its meta-info) the
> >>immutable versus modifiable information.  This could be done at the
> >>level of individual context entries, individual parameter values,
> >>even nodes of a configuration hierarchy.  Based on this
> information,
> >>a container could assess the scope of re-deployment that a
> particular
> >>component implementation supports and handle the resumption cycle
> >>accordingly.
> >>
> >>
> >
> >Add this information to .xinfo? It can then be held in the
> component code as
> >JavaDoc and generated with XDoclet.
> >
> Yep.
> >>My 0.02 euro on a Sunday afternoon.
> >>
> >
> >And very good value too.
> >
> Must be all of the sunshine!
> Cheers, Steve.
> >
> >
> >-- Steve

So, in conclusion, what we appear to be saying is that...

1) Reconfiguration of mutable properties takes place when a component is
2) Mutable properties are declared in a component's .xinfo
2) Avalon will take care of suspending/resuming the container components it
is managing
3) The Mailet container will take care of suspending/resuming the mailets it
is managing
4) The default container implementation of suspend is to invoke destroy()
and of resume is to invoke init()

Looks like there is lots to do! Do you know if there is currently any
roadmap for any of this on the Avalon side?

Thanks for your input,

-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message