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 Steve Brewin <sb...@synsys.com> on 2003/06/26 00:12:28 UTC
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
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
RE: Dynamic Reconfiguration
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: Dynamic Reconfiguration
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Dynamic Reconfiguration
Posted by Steve Brewin <sb...@synsys.com>.
> -----Original Message-----
> From: Richard O. Hammer [mailto:ROHammer@EarthLink.net]
> Sent: 26 June 2003 20:29
> To: James Developers List
> Subject: Re: Dynamic Reconfiguration
>
>
> Steve Brewin wrote:
> > Noel,
> >
> > A few days back we touched on the desirability of being
> able to reconfigure
> > James on the fly. ...
>
> It seems to me dynamic reconfiguration can be achieved with fairly
> run-of-the-mill Java, without needing Avalon, XML, or JMX.
Of course you are correct. Avalon, XML and JMX are all written in Java and
elements of that functionality can be duplicated in Java too, as your code
sample ably demonstrates.
There are questions of responsibilities, avoiding code duplication and
managability.
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.
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. Probably James would use the Java objects as its
configuration source and perist any changes to the Java objects by updating
config.xml.
We could build a home grown interface to expose the configuration parameters
and write a user interface to manipulate them, but why bother? JMX is
specifically designed for this. There are JMX aware management tools that
can be used and JMX bridges to SNMP allowing industry standard management
tools to control JMX enabled applications. Using JMX integrates James into
the management frameworks used by medium to enterprise class organisations.
A major tick mark to have in advancing the widespread adoption of James.
So yes, we could add some levels of dynamic reconfiguration with a bespoke
approach, but in my view there is real value in leveraging industry standard
solutions.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Dynamic Reconfiguration
Posted by "Richard O. Hammer" <RO...@EarthLink.net>.
Steve Brewin wrote:
> Noel,
>
> A few days back we touched on the desirability of being able to reconfigure
> James on the fly. ...
It seems to me dynamic reconfiguration can be achieved with fairly
run-of-the-mill Java, without needing Avalon, XML, or JMX.
To demonstrate this to myself and to anyone else who may be
interested, I have written a demonstration, the source code of which
you may find in the attached zip file.
The demonstration uses a Server which runs a ServerScript again and
again in a loop. A ServerScript consists of a list of tasks which
implement MMPair (general purpose classes meant to mimic
Mailet/Matcher pairs). The Server prints reports of its cycles in a
JFrame, and the tasks print little reports there too.
The ServerScript can be updated dynamically by the Manager, which runs
with Standard.in and Standard.out. While the Server is running you
can copy new instances of MMPair into the dynamicconfiguration
directory (where my classloader can find them) and add these MMPair(s)
to the ServerScript with the "new" command in the Manager. You can
also drop MMPair(s) from the ServerScript with the drop command in the
Manager.
I do not claim this code is robust. It only demonstrates a
possibility. The manager makes no attempt to validate its input; an
input error makes it halt with an error message. Synchronization of
access to the ServerScript has not been addressed in this demo, and it
can break with concurrent access.
If you run this demonstration, keep in mind that the ServerScript is
an ArrayList which is empty until you add tasks from the Manager. The
indexes which you give to the commands [add | new | drop] must be in
the range of the present ArrayList. For instance the first addition
must be at 0, and so on.
Rich Hammer
Hillsborough, N.C.
RE: Mailinglists and CVS are moving
Posted by Danny Angus <da...@apache.org>.
Brian says..
"could do this late Thursday night PST at the earliest."
We'll be sure to let you know.
d.
> -----Original Message-----
> From: Vincenzo Gianferrari Pini
> [mailto:vincenzo.gianferraripini@praxis.it]
> Sent: 26 June 2003 10:37
> To: James Developers List
> Subject: RE: Mailinglists and CVS are moving
>
>
> Danny,
>
> approximately when CVS is expected to move?
>
> Thanks,
>
> Vincenzo
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@apache.org]
> > Sent: giovedì 26 giugno 2003 11.07
> > To: James Developers List
> > Subject: Mailinglists and CVS are moving
> > Importance: High
> >
> >
> > Hi James developers,
> >
> > The James PMC have decided to complete the migration of James to
> > a top level apache project, this affects YOU.
> >
> > The two most important effects are:
> >
> > 1/This list will be closed and a new list
> > server-dev@james.apache.org will replace it
> > 2/CVS module name will be changed from jakarta-james to james-server
> >
> > There will be no overlap of list addresses and module name
> >
> > Keep abreast of the progress of these changes by subscribing to
> > general@james.apache.org
> > To subscribe to general send a mail to
> general-subscribe@james.apache.org.
> >
> > Further information on the changes will be posted to general@ and
> > on the james website. Don't get left behind!
> >
> > d.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
RE: Mailinglists and CVS are moving
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Danny,
approximately when CVS is expected to move?
Thanks,
Vincenzo
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: giovedì 26 giugno 2003 11.07
> To: James Developers List
> Subject: Mailinglists and CVS are moving
> Importance: High
>
>
> Hi James developers,
>
> The James PMC have decided to complete the migration of James to
> a top level apache project, this affects YOU.
>
> The two most important effects are:
>
> 1/This list will be closed and a new list
> server-dev@james.apache.org will replace it
> 2/CVS module name will be changed from jakarta-james to james-server
>
> There will be no overlap of list addresses and module name
>
> Keep abreast of the progress of these changes by subscribing to
> general@james.apache.org
> To subscribe to general send a mail to general-subscribe@james.apache.org.
>
> Further information on the changes will be posted to general@ and
> on the james website. Don't get left behind!
>
> d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Mailinglists and CVS are moving
Posted by Danny Angus <da...@apache.org>.
Hi James developers,
The James PMC have decided to complete the migration of James to a top level apache project, this affects YOU.
The two most important effects are:
1/This list will be closed and a new list server-dev@james.apache.org will replace it
2/CVS module name will be changed from jakarta-james to james-server
There will be no overlap of list addresses and module name
Keep abreast of the progress of these changes by subscribing to general@james.apache.org
To subscribe to general send a mail to general-subscribe@james.apache.org.
Further information on the changes will be posted to general@ and on the james website. Don't get left behind!
d.
RE: Dynamic Reconfiguration
Posted by Steve Brewin <sb...@synsys.com>.
Danny,
> > - How would we add a Matcher/Mailet?
> > Update the configuration, rebuild the mailet chain and send
> init() to the
> > added mailet.
>
> We need to have a graceful way to stop the spooler and
> processors without mail being abandoned between mailets where
> some processing related to a task (processor) has occured but
> not all of it.
Yes. We would have to stop processing new mail and wait for in-process mail
to complete processing. Once the system is 'drained' we could go ahead with
the reconfiguration. When reconfiguration is complete, we can resume
processing mail.
>
> > - How would we remove a Matcher/Mailet?
> > Update the configuration, rebuild the mailet chain and send
> > destroy() to the
> > removed mailet.
>
> ditto above, the problem being when we pause mail destined
> for a removed mailet, where does it go when we resume.
Wouldn't happen if we drained the system as described above.
> > - 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.
>
> I'd rather call it reconfigure()
Then the init() method should be called configure().
> > Adding the refresh() method to the Mailet and Matcher interfaces
> > would break
> > pre-existing code.
>
> Not if we declare it in another interface which mailets can
> optionally implement and only offer reconfiguration to those
> that do support it.
That's what I tried to describe. GenericMatcher and GenericMailet could
implement the new interface and provide a stub method that does nothing.
> > 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.
>
> The effort is the big stumbling block.
Agreed.
> > 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.
>
> I think it is most in demand for production, where small
> mailet pipeline config changes shouldn't require us to stop
> the IO protocols.
> Perhaps we want to change the destination of a "forward" or
> something else "operational"
>
> In fact it would also be nice if we could reconfigure things
> like DNS, Postmaster address etc.
Yes, anything that doesn't require a change to the Avalon environment.
> > Maybe others would wish to comment on if its worth the effort?
>
> Big effort but ultimatly YES worth it if its done well.
Hopefully once there is a clear idea of how it should be done we can break
the effort down into smaller do-able pieces.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Mailinglists and CVS are moving
Posted by Danny Angus <da...@apache.org>.
I should also have pointed out that all subscribers to this list will be automatically transferred to the new list.
RE: Mailinglists and CVS are moving
Posted by Danny Angus <da...@apache.org>.
I should also have pointed out that all subscribers to this list will be automatically transferred to the new list.
Mailinglists and CVS are moving
Posted by Danny Angus <da...@apache.org>.
Hi James users,
The James PMC have decided to complete the migration of James to a top level apache project, this affects YOU.
The two most important effects are:
1/This list will be closed and a new list server-user@james.apache.org will replace it
2/CVS module name will be changed from jakarta-james to james-server
There will be no overlap of list addresses and module name
Keep abreast of the progress of these changes by subscribing to general@james.apache.org
To subscribe to general send a mail to general-subscribe@james.apache.org.
Further information on the changes will be posted to general@ and on the james website. Don't get left behind!
d.
RE: Dynamic Reconfiguration
Posted by Danny Angus <da...@apache.org>.
> - How would we add a Matcher/Mailet?
> Update the configuration, rebuild the mailet chain and send init() to the
> added mailet.
We need to have a graceful way to stop the spooler and processors without mail being abandoned between mailets where some processing related to a task (processor) has occured but not all of it.
> - How would we remove a Matcher/Mailet?
> Update the configuration, rebuild the mailet chain and send
> destroy() to the
> removed mailet.
ditto above, the problem being when we pause mail destined for a removed mailet, where does it go when we resume.
> - 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.
I'd rather call it reconfigure()
> Adding the refresh() method to the Mailet and Matcher interfaces
> would break
> pre-existing code.
Not if we declare it in another interface which mailets can optionally implement and only offer reconfiguration to those that do support it.
> 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.
The effort is the big stumbling block.
> 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.
I think it is most in demand for production, where small mailet pipeline config changes shouldn't require us to stop the IO protocols.
Perhaps we want to change the destination of a "forward" or something else "operational"
In fact it would also be nice if we could reconfigure things like DNS, Postmaster address etc.
>
> Maybe others would wish to comment on if its worth the effort?
Big effort but ultimatly YES worth it if its done well.
d.