james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: Spool/Queue refactoring
Date Sat, 18 Sep 2010 04:19:29 GMT
  +1 much more readable and extensible.

About the long transactions, the downsize is there is more risk to loose 
some mail in case of abrupt failure of the process for example.
DeQueing/EnQueing at each mail process allowed to rely on the spool for 
mail queue persistence between each process.
Now, we may have a longer "grey zone" during which the mail may be lost, 
but I suppose that's the price to pay for performance.

Tks,

Eric


On 17/09/2010 15:09, Norman wrote:
> Hi there,
>
> I just committed some code which change how James handle the queue. 
> Please review the changes and tell me if you see something you don't 
> like about it. I think its a way better then everything we had before ;)
>
> Anyway let me give you some overview on the changes:
>
> * Introduce a MailQueueFactory and MailQueue interface
>    This two interfaces are the core of the new queue stuff. MailQueue 
> does the actual queing/dequeing and MailQueueFactory helps to lookup 
> the queue by name. For now we ship a ActiveMQ implementation.  The 
> interface are currently located in the core-api module. Not sure if we 
> should better move them to an extra module or not. Same goes to the 
> ActiveMQ implementations which are in spoolmanager-function and should 
> better be moved to queue-activemq or something else
>
>
> * Copy the JamesSpoolManager, RemoteDeliver class  and MailContainer, 
> MailProcessor, ProcessorList  (which is now called MailProcessorList 
> and extend MailProcessor) interfaces back from previous trunk version
>   The JamesSpoolManager is responsible to call the dequeue(..) on the 
> MailQueue and pass the Mail objects to the MailProcessList.
>   RemoveDelivery call dequeue(..) on the outgoing queue and try to 
> resend message on temporary erros
>
> * Misc
>   We now do the whole Mailet/Matcher stuff in one long transaction 
> without storing the Mail back the Queue after each MailProcessor. This 
> should give us a performance boost. The downside is that we could have 
> "long transactions".
>
> Just ask if you have any futher questions.
>
> Bye,
> Norman
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


---------------------------------------------------------------------
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