On 2/4/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> in this case, it seems unreasonable to stop
> serving corporate emails just so because some enterprise application
> needs to reconfigure their mailets.
This is kind-of my point, you can re-deploy or reconfigure the
server's behaviour without risking your SLA by remaining "up" for
connectivity. Of course SMTP has solved this by providing a mechanism
for 100% uptime with MX priorities, sadly POP & IMAP don't benefit
from similar.
I don't see this all as conceptually too hard. The spool manager has
a pool of threads that consume messages in a queue (this is basically
what Danny just said). Put the spool manager in a state to not
consume anything on the queue until all the active threads are done...
dump and reload the new configuration for the mailets/matchers, then
let the threads go again. Something similar could be done with POP
and IMAP, though I'm not sure exactly what we would change on the fly.
Spring actually makes this somewhat feasible with the refreshable
application context or even the lifecycle interface, which per the
javadocs, "The typical use case for this is to control asynchronous
processing." This would somewhat hardwire us for spring if we were to
take advantage of that platform.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
