james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [James-NG] Avalon-free James proposal and reference implementation
Date Wed, 02 Feb 2005 23:37:03 GMT
Steve Brewin wrote:
> So, to be clear, taking the Mailet chain as an hypothetical example, we
> would have sequences something like...
> MailetConfiguration(URL anXMLSource)
> MailetProcessor(MailetConfiguration aMailetConfiguration)

My approach would be entirely different to this, just because I don't 
like the contextual lookups that anXMLSource and aMailetConfiguration 
provide.  Something like this...

new JDBCMailet(DataSource)
new UserStoreMailet(UserStore)
new RecipientIsMatcher(String)

These are assembled into a SortedMap or something that goes into...

new SimpleMailetProcessor(MailSpool, SortedMap (of matcher/mailets))

Then hot-restart is as simple as MailetProcessor.dispose(), when that's 
over, then instantiate your new MailetProcessor with the new set of 
Mailets and it starts grabbing.

Or maybe instead of passing MailSpool into the processor...

new SimpleMailetProcessor(SortedMap)

> This is just fine. But let's progress our hypothectical example.
> MailetProcessor.start() and stop() sends start() and stop() to each of its
> Mailets. Some of these Mailets incur significant overheads when starting and
> stopping but have no configuration. None the less, using a simple lfecycle
> with just start() and stop(), they will be started and stopped when we want
> to reconfigure even though it is an unnecessary overhead. Of course, being a
> heavy consumer of resources we absolutely do want to stop cleanly on a
> genuine stop. What we need to be able to signal to these components is that
> we are reconfiguring so that they know that they have to do nothing.

Can you provide examples of a mailet that consumes heavy resources, but 
reloading its configuration would have it do nothing?  I'm having 
trouble thinking of a mailet that has a lot to do initially that 
wouldn't have to be redone with a different configuration.

Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message