Danny Angus ha scritto: > On 5/17/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 messages. 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. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
