You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/06/27 21:03:59 UTC
RE: Dynamic Reconfiguration
> 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
Re[2]: Dynamic Reconfiguration
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Stephen!
SM> One of the things that can be done to make the above scenario more
SM> manageable is to mark state that is supplied to a component by a
SM> container as immutable. For example, it is possible to imagine a
SM> component type declaring (as part of its meta-info) the immutable versus
SM> modifiable information. This could be done at the level of individual
SM> context entries...
In the spirit of these ideas (and being quite wild :-)
what if we just passed _two_ configurations, _two_ contexts, _two_
parameter sets. One of them would be mutable, the other immutable.
This efficiently removes the need to declare entries as
mutable/immutable, we just put them to different conf/context/param.
Nice? :-)
-Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Dynamic Reconfiguration
Posted by Stephen McConnell <mc...@apache.org>.
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
RE: Dynamic Reconfiguration
Posted by Steve Brewin <sb...@synsys.com>.
Noel,
> > 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.
Yep!
> > 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 an extension of the current Configuration interface. One tactic is
to parse the config into Java objects at startup (as now). During runtime
make configuration changes by updating the parsed objects (not supported by
the current Configuration inteface) notifying participants that they have
changed. At shutdown, write the current state of the parsed objects back to
the config (similarly not yet supported).
>
> > 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.
Hmmm. What's a "normal component"? What makes JMX a special case? Once we
expose a public interface for making configuration changes we have no
control over what uses it. This is as it should be. These interfaces should
be secure such that only an authorised entity can make configuration
changes, be it via JMX or another avenue. I'm real keen on JMX but don't
want to exclude the possibility of a non-JMX solution such as a simple
terminal or GUI interface.
>
> Basically, I agree with your thoughts. I am simply
> emphasizing that the
> core integration of (re-)configuration and JMX should be part
> of Avalon.
I totally agree. Ideally James components should see reconfiguration events
triggered by Avalon and act accordingly. Avalon should be in control.
> If
> we do it here, for example if that is something you want to
> undertake, it
> really should be done by contributing to Avalon.
Currently I am just trying to promote a discussion of what needs to be done,
and how, for James to be able to dynamically reconfigure. Personally, I
expect that the eventual conclusion will be that much of the responsibility
will fall on Avalon and James will respond to triggers. But that is just my
opinion.
I'll give it a week, then try and summarise everyones thoughts (on the
Wiki?). See where it goes from there. I know where I'm going at that point -
sailing!
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Dynamic Reconfiguration
Posted by Steve Brewin <sb...@synsys.com>.
Noel,
> > 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.
Yep!
> > 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 an extension of the current Configuration interface. One tactic is
to parse the config into Java objects at startup (as now). During runtime
make configuration changes by updating the parsed objects (not supported by
the current Configuration inteface) notifying participants that they have
changed. At shutdown, write the current state of the parsed objects back to
the config (similarly not yet supported).
>
> > 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.
Hmmm. What's a "normal component"? What makes JMX a special case? Once we
expose a public interface for making configuration changes we have no
control over what uses it. This is as it should be. These interfaces should
be secure such that only an authorised entity can make configuration
changes, be it via JMX or another avenue. I'm real keen on JMX but don't
want to exclude the possibility of a non-JMX solution such as a simple
terminal or GUI interface.
>
> Basically, I agree with your thoughts. I am simply
> emphasizing that the
> core integration of (re-)configuration and JMX should be part
> of Avalon.
I totally agree. Ideally James components should see reconfiguration events
triggered by Avalon and act accordingly. Avalon should be in control.
> If
> we do it here, for example if that is something you want to
> undertake, it
> really should be done by contributing to Avalon.
Currently I am just trying to promote a discussion of what needs to be done,
and how, for James to be able to dynamically reconfigure. Personally, I
expect that the eventual conclusion will be that much of the responsibility
will fall on Avalon and James will respond to triggers. But that is just my
opinion.
I'll give it a week, then try and summarise everyones thoughts (on the
Wiki?). See where it goes from there. I know where I'm going at that point -
sailing!
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org