There's no need to create a MimeMessage.
You do if you want to make any changes to the message, e.g., add a footer,
and until we integrate MIME4J, you need a MimeMessage anytime you want to
parse. Generally, we use our own MimeMessageWrapper, which doesn't load
the
message unless necessary.
In this special case there's no way around loading the message into memory,
unless someone
uses logic like in e.g. MimeMultiPart.parse() for multipart messages without
a ByteArrayStream
as buffer. But most often no changes must be applied and so the MimeMessage
doesnt need to
created.
if you add a custom header you dont have to load the entire
message into memory by calling saveChanges() like in the
LocalDelivery-Mailet.
If I recall correctly, that statement is demonstrably false, and was
tested
to make sure.
I don't know who tested what how but it works for me.
Just take a look at MimeMessage.saveChanges() and
MimeMessage.writeTo(OutputStream os, String[] ignoreList).
All additional headers are stored in a separate list, which is written into
the
outputstream the time writeto is invoked.
LocalDelivery looks like this:
public void service(Mail mail) throws MessagingException {
..
// Prevent MimeMessage loading into memory
if (message instanceof MimeMessageWrapper)
((MimeMessageWrapper)message).addWrapperHeader("Delivered-To",
recipient.toString());
..
and MimeMessageWrapper:
..
/**
* Adds a Header to the wrapper only. The original MimeMessage is not
affected.
* .writeTo(OutputStream headerOs, OutputStream bodyOs, String[]
ignoreList) will write this
* header into the outputstream.
* Purpose: Prevent loading the MimeMessage into memory.
* @param name
* @param value
* @throws MessagingException
*/
public void addWrapperHeader(String name, String value) throws
MessagingException {
if (wheaders == null) {
wheaders = new MailHeaders();
}
wheaders.addHeader(name, value);
}
..
MySQL has (had) a problem with BLOBS and streams;
rewritting the spool and MailImpl to use the FileInputStream
from the tmp-file the e-mail was stored in, can solve this
problem, especially when all e-mails of a certain size are
moved automatically into a FileStore even if a database as
MailStore was specified.
That wouldn't when a database is used for clustering ...
Actually the point is that the FileInputStream of the tmp-file should be
used
wherever possible. This way my database never gets in touch with the content
of
the e-mail serviced by RemoteDelivery cause it writes directly from the
FileInputStream.
And if RemoteDelivery fails I only save the path of the file.
If someone wants use a cluster I'd say that by default this behaviour should
be
disabled, unless the software takes care of it.
MD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
