MimeMessages are built in a lazy way when there is a need to parse or
alter the message.
As long as you receive and spool a message without altering its content
then MimeMessage will never be parsed.
We extensively use our MimeMessageWrapper that is an extension of
MimeMessage made to delay the parsing of the headers and the parsing of
the body as much as possible, with the best scenario of no parsing.
You should be aware that we anyway currenlty load the full message
stream in a bytearray in memory, so to handle 10 concurrent messages
each one of 10MB serialized you'll need at least 100MB only for the
buffers (IIRC james ends up using the double of this memory, but I never
analyzed the details).
Stefano
[EMAIL PROTECTED] ha scritto:
Hi guys,
I've been watching James for some time now and have been very impressed. I
have a project which I think is perfect for James. But I have some questions
in regards to when and where JavaMail is used.
Our past experience with JavaMail has been disappointing. We still use it but
mostly for its utility classes. From what I understand its still too strict
and still takes up too much memory. I know that you guys are looking to
de-couple javamail from James but I really need to get this project going soon
so I'm hoping that JavaMail is not used at all for the SMTP server and the
Spool.
So when and where is JavaMail used? In particular when does it create
instances of MimeMessages and call any methods on a MimeMessage instance?
I've looked at the SMTP process and it doesn't seem to use JavaMail at all.
I'll be looking at the Spool next. I'm hoping it also uses JavaMail sparsely
or for limited instances.
Regards,
Roy Rim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
