Re: Spool/Queue refactoring
Im currently working on some improvements, which will help to handle big messages more efficient. So stay tuned! Bye Norman 2010/9/18, Norman Maurer : > Thx for the Feedback. Im sure there is still plenty of room for > improvments. > > But I think it Shows the idea. > > Bye > Norman > > 2010/9/18, Eric Charles : >> OK. >> Apart those activemq exceptions in log that will be soon fixed, new >> spool is working fine on my side. >> Many tks for this new architecture enhancement :) >> Eric >> >> >> On 18/09/2010 08:07, Norman Maurer wrote: >>> Yeah thats how transactions should work.. >>> >>> BTW if some of you notice this exception: >>> >>> INFO 07:39:44,414 | >>> org.apache.activemq.broker.TransportConnection.Transport | Transport >>> failed: org.apache.activemq.transport.TransportDisposedIOException: >>> Peer (vm://localhost#51) disposed. >>> org.apache.activemq.transport.TransportDisposedIOException: Peer >>> (vm://localhost#51) disposed. >>> at >>> org.apache.activemq.transport.vm.VMTransport.stop(VMTransport.java:159) >>> at >>> org.apache.activemq.transport.vm.VMTransportServer$1.stop(VMTransportServer.java:81) >>> at >>> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) >>> at >>> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) >>> at >>> org.apache.activemq.transport.ResponseCorrelator.stop(ResponseCorrelator.java:132) >>> at >>> org.apache.activemq.util.ServiceSupport.dispose(ServiceSupport.java:43) >>> at >>> org.apache.activemq.ActiveMQConnection.close(ActiveMQConnection.java:656) >>> at >>> org.apache.activemq.pool.ConnectionPool.close(ConnectionPool.java:130) >>> at >>> org.apache.activemq.pool.ConnectionPool.expiredCheck(ConnectionPool.java:161) >>> at >>> org.apache.activemq.pool.ConnectionPool.decrementReferenceCount(ConnectionPool.java:148) >>> at >>> org.apache.activemq.pool.PooledConnection.close(PooledConnection.java:71) >>> at >>> org.apache.james.queue.ActiveMQMailQueue.deQueue(ActiveMQMailQueue.java:120) >>> at >>> org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:155) >>> at java.lang.Thread.run(Thread.java:717) >>> >>> Its harmless and will be fixed in activemq 5.4.1, which will be >>> released during the weekend (I hope) >>> >>> http://www.manning-sandbox.com/thread.jspa?messageID=103340 >>> https://issues.apache.org/activemq/browse/AMQ-2902 >>> >>> Bye, >>> Norman >>> >>> 2010/9/18 Eric Charles: Yes for Exceptions. Sorry, I was not precise enough. I was talking of java process crash (jvm crash, kill -9,...). If the mail is longer out-of-the-queue, there are more chance that the crash (if any) occurs during that period. (I suppose that the queue is responsible to restore its content, even in cash of jvm crash,...) Does it makes sense? Tks, Eric On 18/09/2010 07:29, Norman Maurer wrote: > 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: >> +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 Mail
Re: Spool/Queue refactoring
Thx for the Feedback. Im sure there is still plenty of room for improvments. But I think it Shows the idea. Bye Norman 2010/9/18, Eric Charles : > OK. > Apart those activemq exceptions in log that will be soon fixed, new > spool is working fine on my side. > Many tks for this new architecture enhancement :) > Eric > > > On 18/09/2010 08:07, Norman Maurer wrote: >> Yeah thats how transactions should work.. >> >> BTW if some of you notice this exception: >> >> INFO 07:39:44,414 | >> org.apache.activemq.broker.TransportConnection.Transport | Transport >> failed: org.apache.activemq.transport.TransportDisposedIOException: >> Peer (vm://localhost#51) disposed. >> org.apache.activemq.transport.TransportDisposedIOException: Peer >> (vm://localhost#51) disposed. >> at >> org.apache.activemq.transport.vm.VMTransport.stop(VMTransport.java:159) >> at >> org.apache.activemq.transport.vm.VMTransportServer$1.stop(VMTransportServer.java:81) >> at >> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) >> at >> org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) >> at >> org.apache.activemq.transport.ResponseCorrelator.stop(ResponseCorrelator.java:132) >> at >> org.apache.activemq.util.ServiceSupport.dispose(ServiceSupport.java:43) >> at >> org.apache.activemq.ActiveMQConnection.close(ActiveMQConnection.java:656) >> at >> org.apache.activemq.pool.ConnectionPool.close(ConnectionPool.java:130) >> at >> org.apache.activemq.pool.ConnectionPool.expiredCheck(ConnectionPool.java:161) >> at >> org.apache.activemq.pool.ConnectionPool.decrementReferenceCount(ConnectionPool.java:148) >> at >> org.apache.activemq.pool.PooledConnection.close(PooledConnection.java:71) >> at >> org.apache.james.queue.ActiveMQMailQueue.deQueue(ActiveMQMailQueue.java:120) >> at >> org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:155) >> at java.lang.Thread.run(Thread.java:717) >> >> Its harmless and will be fixed in activemq 5.4.1, which will be >> released during the weekend (I hope) >> >> http://www.manning-sandbox.com/thread.jspa?messageID=103340 >> https://issues.apache.org/activemq/browse/AMQ-2902 >> >> Bye, >> Norman >> >> 2010/9/18 Eric Charles: >>> Yes for Exceptions. >>> >>> Sorry, I was not precise enough. I was talking of java process crash >>> (jvm >>> crash, kill -9,...). >>> If the mail is longer out-of-the-queue, there are more chance that the >>> crash >>> (if any) occurs during that period. >>> (I suppose that the queue is responsible to restore its content, even in >>> cash of jvm crash,...) >>> Does it makes sense? >>> >>> Tks, >>> Eric >>> >>> >>> On 18/09/2010 07:29, Norman Maurer wrote: 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: > +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 >
Re: Spool/Queue refactoring
OK. Apart those activemq exceptions in log that will be soon fixed, new spool is working fine on my side. Many tks for this new architecture enhancement :) Eric On 18/09/2010 08:07, Norman Maurer wrote: Yeah thats how transactions should work.. BTW if some of you notice this exception: INFO 07:39:44,414 | org.apache.activemq.broker.TransportConnection.Transport | Transport failed: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#51) disposed. org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#51) disposed. at org.apache.activemq.transport.vm.VMTransport.stop(VMTransport.java:159) at org.apache.activemq.transport.vm.VMTransportServer$1.stop(VMTransportServer.java:81) at org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) at org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) at org.apache.activemq.transport.ResponseCorrelator.stop(ResponseCorrelator.java:132) at org.apache.activemq.util.ServiceSupport.dispose(ServiceSupport.java:43) at org.apache.activemq.ActiveMQConnection.close(ActiveMQConnection.java:656) at org.apache.activemq.pool.ConnectionPool.close(ConnectionPool.java:130) at org.apache.activemq.pool.ConnectionPool.expiredCheck(ConnectionPool.java:161) at org.apache.activemq.pool.ConnectionPool.decrementReferenceCount(ConnectionPool.java:148) at org.apache.activemq.pool.PooledConnection.close(PooledConnection.java:71) at org.apache.james.queue.ActiveMQMailQueue.deQueue(ActiveMQMailQueue.java:120) at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:155) at java.lang.Thread.run(Thread.java:717) Its harmless and will be fixed in activemq 5.4.1, which will be released during the weekend (I hope) http://www.manning-sandbox.com/thread.jspa?messageID=103340 https://issues.apache.org/activemq/browse/AMQ-2902 Bye, Norman 2010/9/18 Eric Charles: Yes for Exceptions. Sorry, I was not precise enough. I was talking of java process crash (jvm crash, kill -9,...). If the mail is longer out-of-the-queue, there are more chance that the crash (if any) occurs during that period. (I suppose that the queue is responsible to restore its content, even in cash of jvm crash,...) Does it makes sense? Tks, Eric On 18/09/2010 07:29, Norman Maurer wrote: 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: +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...@jam
Re: Spool/Queue refactoring
Yeah thats how transactions should work.. BTW if some of you notice this exception: INFO 07:39:44,414 | org.apache.activemq.broker.TransportConnection.Transport | Transport failed: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#51) disposed. org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#51) disposed. at org.apache.activemq.transport.vm.VMTransport.stop(VMTransport.java:159) at org.apache.activemq.transport.vm.VMTransportServer$1.stop(VMTransportServer.java:81) at org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) at org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) at org.apache.activemq.transport.ResponseCorrelator.stop(ResponseCorrelator.java:132) at org.apache.activemq.util.ServiceSupport.dispose(ServiceSupport.java:43) at org.apache.activemq.ActiveMQConnection.close(ActiveMQConnection.java:656) at org.apache.activemq.pool.ConnectionPool.close(ConnectionPool.java:130) at org.apache.activemq.pool.ConnectionPool.expiredCheck(ConnectionPool.java:161) at org.apache.activemq.pool.ConnectionPool.decrementReferenceCount(ConnectionPool.java:148) at org.apache.activemq.pool.PooledConnection.close(PooledConnection.java:71) at org.apache.james.queue.ActiveMQMailQueue.deQueue(ActiveMQMailQueue.java:120) at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:155) at java.lang.Thread.run(Thread.java:717) Its harmless and will be fixed in activemq 5.4.1, which will be released during the weekend (I hope) http://www.manning-sandbox.com/thread.jspa?messageID=103340 https://issues.apache.org/activemq/browse/AMQ-2902 Bye, Norman 2010/9/18 Eric Charles : > Yes for Exceptions. > > Sorry, I was not precise enough. I was talking of java process crash (jvm > crash, kill -9,...). > If the mail is longer out-of-the-queue, there are more chance that the crash > (if any) occurs during that period. > (I suppose that the queue is responsible to restore its content, even in > cash of jvm crash,...) > Does it makes sense? > > Tks, > Eric > > > On 18/09/2010 07:29, Norman Maurer wrote: >> >> 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: >>> >>> +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 >>> >>> --
Re: Spool/Queue refactoring
Yes for Exceptions. Sorry, I was not precise enough. I was talking of java process crash (jvm crash, kill -9,...). If the mail is longer out-of-the-queue, there are more chance that the crash (if any) occurs during that period. (I suppose that the queue is responsible to restore its content, even in cash of jvm crash,...) Does it makes sense? Tks, Eric On 18/09/2010 07:29, Norman Maurer wrote: 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: +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 - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Spool/Queue refactoring
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 : > +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
Re: Spool/Queue refactoring
+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
Spool/Queue refactoring
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
