Kind of.. I would try to refactor the code a bit more to make it easy to replace javamail Transport usage for SMTP later etc. Also I would try to hook in kind of plugins for postprocessing and jmx stats.
I think the memory/cpu is not really a problem. It should not be notable. The IO should also not be a big problem as we most times only need to move the envelop of the mail and nothing more.. Bye, Norman 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) > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
