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
