Hi,
Tks for the information.
What about the jsieve functions? We'll we reimplement it or reuse the
existing mailet?
Tks,
Eric
On 10/01/2011 10:54, Stefano Bagnara wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
