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