james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Thu, 17 May 2007 15:30:42 GMT
Danny Angus ha scritto:
> On 5/17/07, Stefano Bagnara <apache@bago.org> wrote:
>> My JAMES Server deployment with bigger throughput does never parse
>> mimemessages.
>> I don't use any mailet using properties from the MimeMessage object, and
>> SMTP+POP3+RemoteDelivery simply works without parsing.
>> Maybe I could not deliver 1 million mails per day if I had mime parsing
>> somewhere...
> Seems to me we need to get some benchmarks on the hit parsing adds,
> I'm not convinced it needs to be so significant.
> d.

I worked on lazy-loading (and no-loading at all) optimizations for
MimeMessageWrapper (and its CoW) mainly because I was not able to reach
that throughput before.

In JAMES Server 2.x specific case, having javamail parsing the messages
in memory I also often hit OutOfMemory errors before that change.

In the case of outgoing mail (mail generated by the server, submitted
via smtp from authorized network/users, forwarded because we are
secondary host or because we simply do relay for some domain) even the
"simple storage" is critical in performance for high-throughput: that's
why I also investigated the use of ActiveMQ's Kaha Persistence engine
for faster (lightweight) operations in case of many small short living

Btw I don't want to take this discussion too far. I just simply wanted
to tell Jukka that if the JCR is able to support simple streams with low
overhead, with a good usage of streams (never load in memory full
contents) and maybe good support for thousands of slow connections in a
SEDA architecture imho we'll have it much more usable in many scenarios.
Otherwise it will fit a very limited usecase and we'll have to skip the
"let's use JCR as THE interface" proposed by Noel.

Either way, I'm happy to see some new code and new people working on it.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message