james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject [Fwd: Re: Dynamic Reconfiguration]
Date Sun, 29 Jun 2003 23:09:39 GMT


-------- Original Message --------
Subject: 	Re: Dynamic Reconfiguration
Date: 	Sun, 29 Jun 2003 16:35:15 +0200
From: 	Stephen McConnell <mcconnell@apache.org>
Reply-To: 	Avalon Developers List <dev@avalon.apache.org>
To: 	Avalon Developers List <dev@avalon.apache.org>
CC: 	dev@avalon.apache.org
References: 	<NBBBJGEAGJAKLIDBKJOPEEOFCHAB.noel@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


Mime
View raw message