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)
Tks,
Eric
On 10/01/2011 10:35, Norman Maurer wrote:
Hi there,
comments inside...
2011/1/10 Eric Charles<e...@apache.org>:
Hi Norman,
I see two attention points there:
- Additional operational components to be managed/monitored (the
intermediate delivery queues, jms or whatever), but I see you already began
to take it into account with JAMES-1180 (Allow to browse MaillQueue)
And I would like to allow the monitoring / management of the
RemoteDelivery and LocalDelivery service once they are core
components/services.. Like get stats how many temporary errors we got
(smtp 4xx code), how many permanent (smtp 5xx code) etc..
- Which configuration/processing framework would be used to consume the
delivery queues: mailets api (we can let it evolve to take new requirements
into account), camel-like routes, custom james-made,... ?
We would just use threads which will call MailQueue.deQueue() and then
dispatch them.. So its exactly the same as we do in JamesMailSpooler
and RemoteDelivery mailet atm.
The good impacts are:
- We would have a better separation of concern: mailets to decide what to do
with the delivery, and the delivery as such.
- Both concerns/aspects will have their own configuration and own
implementation, so not everything bloated in mailetconainer modules/conf
files.
- It may be more easy to route based on policies, scheduling,... and also to
deliver spam/virus/... in mailbox.
Tks,
Eric
On 9/01/2011 10:07, Norman Maurer wrote:
Could you explain what Problems you See here?
Also the Queues would Be of the type MailQueue, so its not limited to
jms. The configuration of the Services would Be Done by seperate
config Files....
Bye
Norman
Am Sonntag, 9. Januar 2011 schrieb Eric
Charles<eric.char...@u-mangate.com>:
Hi,
I also like the idea to have remote/local delivery as core service
implemented via JMS queues.
The decision to deliver should remain in the mailet processor.
The way the local/remote delivery queues will be consumed will be
configured via separate mechanisms (xml files).
The question is also "how to configure the local/remote delivery queues
consuming": via another mailet chain, via camel-like routes, yet-another
ad-hoc config ?
Don't we simply move the problem from the current mailet processors to an
other component, with JMS queues between ?
But yes, I like the idea.
Tks,
Eric
On 8/01/2011 19:10, Norman Maurer wrote:
Well I thought more about doing the splitting in the Delivery
dispatcher.. something like:
* retrieve mail from queue
* check if mail attribute "prepared" set
* attribute not found:
* do the splitting if needed
* set attribute "prepared"
* store back in queue
* attribute found:
* start delivering
This would allow is todo the configure of the gateway etc only one
time and all at the same place.
The other think we could do is configure in the "ToRemoteDelivery" and
store the config stuff as mail attributes, but this is not so
"clean"..
I would prefer 1)
WDYT ?
Norman
2011/1/8 Stefano Bagnara<apa...@bago.org>:
2011/1/7 Norman Maurer<nor...@apache.org>:
Hi there,
I spend the last weeks to think about RemoteDelivery and how it is
implemented. I think putting the remote deliver code in a Mailet is
not a good idea. It does not give us much control about it and makes
it harder to customize or extend. I think it would make more sense to
make the delivery code a "core service" which should allow some kind
of pluggable policy out-of-the-box. The Mailet should just move the
mail to the right queue then which the mail will get pulled of from
the new "core service" and tried to get delivered.
Beside of that I think we should add some kind of policy support which
allow to register policies/listener which customize the following
things:
* Calculate the next delay
* Force an other ip address as source for the next delivery attemp
* Force an other ip address as destionation for the next delivery attemp
After that is done I think it would be very easy to add JMX metrics to
the service as well...
WDYT ?
Do you think of simply using a ToRepository or something more specific?
The main issue with using a simple ToRepository is that currently
RemoteDelivery had some "logic" before writing to the outgoing spool.
In fact depending on the presence of a gateway conf or not it will
split the message for each recipient (or recipient group) depending on
the final domain.
If we instead use a simple ToRepository then we'll have to do one more
processing in order to split the message in a following step.
So, i think we should still have a ToRemoteDelivery mailet or something
similar.
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Bye,
Norman
---------------------------------------------------------------------
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
