james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: [PROPOSAL] Using Camel as replacement of MailProcessor / SpoolManager
Date Fri, 19 Feb 2010 08:43:38 GMT
Hi Stefano,

comments inside...


2010/2/19 Stefano Bagnara <apache@bago.org>:
> 2010/2/18 Norman Maurer <norman@apache.org>:
>> Hi all,
>>
>> in the past Stefano told me about his Idea of using camel within james
>> (it was just an idea and he had no closer look yet). The last days I
>> did some research about camel (camel.apache.org) and I think he is
>> right.
>
> To be true the idea was not mine, but from James Strachan:
> http://markmail.org/message/vzzmwm3kdv66r3ce
> (expecially last senteces).

Thx for the pointer to the archives..


>
>> So me plan is:
>>
>> * Write a Consumer for our SpoolRepository which would fire of an
>> exchange object when a mail object is ready for processing
>> * Write a RouteBuilder which will create a route for every configured
>> processor  and so replace the MailProcessor stuff at all. The route
>> would just to the Matcher, Mailet processing
>
> IIUC you are trying to keep using the current repository
> implementation but use camel for routing. This sounds like an
> intermediate steps, not sure it's easier (as I never had the time to
> investigate on Camel internals). IIUC in your plan you keep using our
> spoolmanager xml definition to describe how processors are and then
> use camel as an alternative implementation of the "LinearProcessor"
> (and you would still use the StateAwareProcessorList and our
> repositories).

Not quite right. I would remove the LinearProcessor and
StateAwareProcessorList at all. Let me outline the idea a bit more:

I would just parse the spoolmanager.xml and create routes per
processor via the RouteBuilder class. So it would be one Route per
processor. Which processor to use will be detect by check the Camel
message header.

So I would write some kind of Camel Processor Mailet wrapper to call
the mailet, and a Camel Splitter to split the Mail for the Matcher
stuff.

They Mail objects will get "injected" in the Camel route by an
SpoolRepositoryConsumer. The Consumer will fire the Mail to the Route
when the spoolRepository.accept() return a Mail object.


>
> The original idea was to simply replace the whole spooling and
> SpoolManager with a Camel based component. This would mean dropping
> the SpoolRepository interface at all and just use Camel Transport
> (activemq/JMS as we probably want persistent queues).

I agree this would be the "final" solution. I just want todo the
refactoring step by step to get a better overview and idea about it.
Replace the SpoolRepositoryConsumer with something else should be
really easy once the rest is in place..

>
> MailServer and MailetContext services then would change to send the
> message to Camel or maybe we should change the 2 services with a
> simpler service send(Mail/Envelope/Exchange message,
> String/URL/Address destination).

+1

>
> As a POC this could work but to be production ready we'll have to also
> make the envelope/message split and (like Robert say in his reply)
> stream the message content to some storage and only route around the
> envelope (the main issue here is reference counting when we duplicate
> the envelope as this happens a lot in james).
>

True enough.. But I think the KISS principal is the way to go for
now.. We can refactor it later to make it more performant.

> Take this only as "brainstorming", if you already have a clear idea on
> the plan go ahead with your plan: we need some real experience with
> camel to see if it really is as good as it sounds :-)
>
> Stefano
>
> ---------------------------------------------------------------------

Thx for you comments..

Bye,
Norman

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message