No you can't loose the mail, it will rollback the transaction on an error and so let the mail in the queue.
Bye. Norman 2010/9/18 Eric Charles <e...@apache.org>: > +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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
