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 <e...@apache.org>: > 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<e...@apache.org>: >>> 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<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 >>>> >>> >>> --------------------------------------------------------------------- >>> 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
