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
