Hi there, comments inside...
2011/1/10 Eric Charles <[email protected]>: > 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<[email protected]>: >>> >>> 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<[email protected]>: >>> >>> 2011/1/7 Norman Maurer<[email protected]>: >>> >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
