Robert Burrell Donkin ha scritto:
On Tue, Jun 24, 2008 at 7:40 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
About my concern it still applies also to the scenario where only the
"Envelope" (to be defined) is written on every queue change, but this cannot
be avoided with the suggested approach unless we switch to non-persistent
queues.
i think a mixture of persistent and non-persistent would probably work best.
but there should be no need to hardwire which queues are persistent:
the configuration should build this at run time
I agree.
Sometimes my JAMES deal with around a million email in a day and I had to
"hack" some JAMES code to avoid writing to disk/jdbc on each status change
(custom processorClass for the spoolmanager).
A performance oriented approach would be to directly use the KAHA engine
[1] (or maybe the AMQ Message Stores [2]) o to write stuff only for
reliability but keep using memory operations unless the queue grow too much,
but I think this should be kept in our mind when we'll refactor the
repository APIs (let's not close this door when we change the api)
should be easy enough if we go down the MOM route: messaging intefaces
tend to be concise which allows multiple implementations
Issues:
It would be cool to be able to declare some processing to be done before
finally declaring the mail as accepted. Specification say we should
reply as fast as possible after the DATA ending "CRLF.CRLF" to avoid
duplicate sent, but I think many times 0.1 seconds are enough to run
some processing and "fast fail" instead of spooling.
It would be even better to say: start the spooling process, track the
status for 0.1 seconds and then replies to the DATA.
I say this because I think that we need message tracking during the
spool in order to support delivery status notification at the container
level. JAMES currently support a limited part of DSNs (bounces) at the
mailet level but this is not enough (IMHO).
The container should be made aware of messages being delivered, messages
being expanded, delayed, failed, aliased in order to provide better
tracking (both for DSN and logging purposes).
They're 3 years I think to this from time to time, but I never found a
satisfying solution, yet.
It would be cool if a standard SMTP=>MultipleMailets=>RemoteDelivery
processing could be done with a single write to disk when the mail is
accepted and no other read/write (unless memory/queues are full).
unless you're willing to risk losing messages, i don't see how this
can be done. it should be possible to just write twice: once when the
message arrives and once when processing is done.
"done marks" could be applied in batches when the traffic is really
high. But maybe this is premature optimization.
If we can get it writing twice it would be already a big improvement.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
