You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stephen McConnell <mc...@apache.org> on 2003/06/30 01:09:39 UTC
[Fwd: Re: Dynamic Reconfiguration]
-------- Original Message --------
Subject: Re: Dynamic Reconfiguration
Date: Sun, 29 Jun 2003 16:35:15 +0200
From: Stephen McConnell <mc...@apache.org>
Reply-To: Avalon Developers List <de...@avalon.apache.org>
To: Avalon Developers List <de...@avalon.apache.org>
CC: dev@avalon.apache.org
References: <NB...@devtech.com>
Noel:
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.
In this picture the open question is the semantic applicable during a
"resumption" phase. It is reasonable to assume that context entries are
immutable? It is possible that we may want to change the temporary
working directory used by the component? Perhaps we want to apply a
logging channel that has been reconfigured to use a different output
target or priority? Perhaps we want to swap the source provider
component for a DNS service with another provider? Maybe some
parameters need to be propagated to the component, or potentially some
configuration information needs to be reassessed. All of these question
concern state that is supplied by a container to a component - and all
represent reasonable candidates for "re-assessment".
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.
In practice, the process of resumption could be viewed as re-application
of the lifecycle stages, qualified relative to the immutable state of
the respective artifacts (e.g. if logging is declared as immutable by a
component implementation, then it makes no sense for a container to
allow or attempt to apply a change). In fact, this constraint could be
pushed back to the management access point such that the initiation of
change potential within a client interface could be qualified by the
component meta info.
My 0.02 euro on a Sunday afternoon.
Cheers, Steve.
Noel J. Bergman wrote:
>>Avalon frameworks manage the core tasks and should ideally manage the
>>reconfiguration of those tasks. Achieving this means that all Avalon
>>components benefit from these advances.
>>
>
>Ideally, yes. This is something that we should bring up with Avalon, not
>just here. They should provide the core facilities, and we should know how
>to use them.
>
>
>>The configuration file, config.xml, is essentially a persistent store for
>>the configuration parameters. As it is XML based we may as well go with
>>
>it.
>
>>We may well want to expose the parsed parameters as Java objects through
>>some kind of interface.
>>
>
>You mean, other than the existing ones?
>
>
>>Probably James would use the Java objects as its configuration source
>>and perist any changes to the Java objects by updating config.xml.
>>
>
>Avalon provides the configuration interfaces, and should be responsible for
>the core support. However, I would not want to see normal components able
>to effect configuratin changes. The JMX support should be able to do so.
>
>Basically, I agree with your thoughts. I am simply emphasizing that the
>core integration of (re-)configuration and JMX should be part of Avalon. If
>we do it here, for example if that is something you want to undertake, it
>really should be done by contributing to Avalon.
>
> --- Noel
>
>cc: dev@avalon.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: [Fwd: Re: Dynamic Reconfiguration]
Posted by Steve Brewin <sb...@synsys.com>.
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).
Yep!
> >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
container.
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
look.
>
> >>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
container.
>
> >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
suspended
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
Re: [Fwd: Re: Dynamic Reconfiguration]
Posted by Stephen McConnell <mc...@apache.org>.
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.html - 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).
>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?
>>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).
>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
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: [Fwd: Re: Dynamic Reconfiguration]
Posted by Steve Brewin <sb...@synsys.com>.
-------- Original Message --------
Subject: Re: Dynamic Reconfiguration
Date: Sun, 29 Jun 2003 16:35:15 +0200
From: Stephen McConnell <mc...@apache.org>
Reply-To: Avalon Developers List <de...@avalon.apache.org>
To: Avalon Developers List <de...@avalon.apache.org>
CC: dev@avalon.apache.org
References: <NB...@devtech.com>
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.html - this seems
an entirely sensible approach.
It is important that we have control over the order that components are
suspended and resumed. 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.
> 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!
Maybe we have to add a default implementation of suspend/resume for all
components, where suspend invokes destroy() and resume invokes init().
Unfortunatley, there is a high chance of components that (incorrectly) do
not cleanly release resources in destroy() which were acquired during init()
failing.
> 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.
> My 0.02 euro on a Sunday afternoon.
And very good value too.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org