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