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