> we might consider adopt a technology which would allow us
> to distribute James in the same manner as EJB's deployed
> in different containers connecting to each other using
> JNDI and RMI.
We're already close. The linkages between SMTP, NNTP, POP3, IMAP and the
pipeline are all through the spooler or the repositories. I've been toying
with the idea of a distributed spooler for most of the year. The problem is
that we have to synchronize access to items (only one processor should take
an item for processing), and we need to recover if a processor fails to
complete processing of an item.
These issues are why I've started to think that instead of a distributed
spool mechanism, we should consider a central spooler with clustered
processors. It would be easier to control and recover, since the spooler
would control access, and would know if a processor failed.
> JMS is probably my least familiar EJB technology, but as we've somewhat
> already agreed that we want to separate mail repository from spooling
> notions, JMS might fit very well.
Nitpick: JMS is a J2EE technology, not an EJB technology. I have no
experience using JMS, but it seems overkill for many purposes. I've always
had a fondness for the COS Event Service, myself.
> On the whole I think I'd like to see a requirement for James to be
> distributable, with services deployed remotely from each other.
Agreed.
> We I suspect would then be able, using our current workflow, to offer
> scaleability, redundancy and fail-over for almost every service.
If we change the configuration files, I think that you'll find that we are
really, really, close to being there, if not already there, except that the
spooler would be a single process, not clustered.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
