james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Means" <cme...@intfar.com>
Subject RE: Dynamic Reconfiguration
Date Thu, 26 Jun 2003 02:44:25 GMT
I think it would also be nice to be able to change the order of the mailets,
and change the "criteria" for a mailet's matcher.

What about a "test" mode so that changes could be validated/tested before
being put on-line?

> -----Original Message-----
> From: Steve Brewin [mailto:sbrewin@synsys.com]
> Sent: Wednesday, June 25, 2003 5:12 PM
> To: James Developers List (E-mail)
> Subject: Dynamic Reconfiguration
>
>
> Noel,
>
> A few days back we touched on the desirability of being able to
> reconfigure
> James on the fly.
>
> Having given this a little thought I think there are two levels to this...
>
> 1) Tasks - They are managed by Avalon and Avalon would need to have the
> ability to manage and signal a reconfiguration events, such as start,
> suspend, resume, stop, add, remove, and modify task.
>
> 2) Transport Matchers and Mailets - They are managed by James and the
> ability can be added to James to manage and signal reconfiguration events.
> As the Mailet chain is a logical construct, the concept of starting,
> suspending, resuming or stopping an individual Mailet cannot apply as the
> logical construct would breakdown. We can add, remove and modify.
>
> So lets look at what can be done in (2) in more detail...
>
> - How would we add a Matcher/Mailet?
> Update the configuration, rebuild the mailet chain and send init() to the
> added mailet.
>
> - How would we remove a Matcher/Mailet?
> Update the configuration, rebuild the mailet chain and send
> destroy() to the
> removed mailet.
>
> - How would we modify a Matcher/Mailet?
> Update the configuration and send refresh() to the modified mailet.
>
> Only two new concepts are introduced here, an updateable configuration and
> the addition of the refresh() method to the Mailet and Matcher interfaces.
>
> Currently configurations are not updateable as
> org.apache.avalon.framework.configuration.Configuration does not
> support the
> setting of values or attributes. Ideally it should. They could
> then be made
> editable by exposing to a management interface such as JMX. At
> termination,
> a changed configuration would be written back to config.xml, ensuring
> synchronization.
>
> Adding the refresh() method to the Mailet and Matcher interfaces
> would break
> pre-existing code. GenericMailet and GenericMatcher could be fixed, but
> there is no rule that says these should be subclassed for all Mailets and
> Matchers. Better to extend the interfaces with one which adds the
> refresh()
> method and implement this in the Generic classes as a no-op.
>
> So, dynamic reconfiguration of the Transport Matchers and Mailets could be
> achieved more easily than full dynamic reconfiguration which
> requires Avalon
> support, but not without a fir amount of effort.
>
> I am not sure what the demand for dynamic reconfiguration is. Its
> great for
> developers in a code/test/fix cycle, lethal if abused in a production
> environment but sometimes a life-saver.
>
> Maybe others would wish to comment on if its worth the effort?
>
> -- Steve
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
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