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 :
> 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/1
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 :
> 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
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:
IN
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
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,
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 :
> +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 fail
+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.
No
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 MailQ
