2011/1/10 Eric Charles <e...@apache.org>: > So configuration and code would the same for now, simply export them to > separate components (additional conf file and maven module I guess) ? > > As side effect, we should have in mind: > - More resources (memory / cpu / I/O) for the delivery threads and queues. > - Additional delay for the mails to be delivered (it goes via additional > intermediate step) (Not very relevant, mail is store/forward, not real-time)
At the moment we already have a specific spool queue for the remote delivery (the outgoing queue). So every mail to be remotely delivered will be removed from the main spool and placed into the outgoing queue. A remote delivery thread will then read one mail from the queue and attempt to deliver it. IMHO this behaviour will be preserved even if remote delivery is an external service and this should not introduce more delay, more steps or more resources. In fact the current RemoteDelivery runs its own threads for processing and IMHO it is wrong that a mailet use similar resources like threads. A mailet should be as stateless as possible in order to make it easier to understand how it works, in order to allow distributed environments to distribute the load between different machines without side effects. This is not required by the mailet api, but I think it makes sense moving towards this. Either way RemoteDelivery is not a generic mailet and it won't work in another mailet container, so there is not much reasons to insist it being a mailet: or at least not a mailet that runs against the main spool. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
