On 1/13/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Samstag, den 13.01.2007, 16:30 +0000 schrieb robert burrell donkin:
> (moving on list from https://issues.apache.org/jira/browse/JAMES-760)
>
> TorqueMimeMessage uses a byte arrays for the message bodies and the
> MimeMessage is completely built up before being returned.
>
> this is great when you want to do mailet processing but is more
> resource hungry (when using a protocol such as IMAP) than simply
> pushing the data down the pipe to the client without using a byte
> array.
This could be perfectly done when you are reading the data from file
system, as it is planned for the future. The optimal way is just passing
over the InputStream, of course.
AFAIK current JDBC drivers (except oracle?) are not able to stream BLOBs
without loading it completely into memory.
Another problem could be transferring a big message (20MB) over a slow
dialup connection, which would block one DB connection for a long time.
So with JDBC there is probably no way to avoid the byte array for the
body.
this is one area where hybrid file-database data stores (such as JCRs)
may well have performance benefits over pure database implementations
One improvement can be loading the body lazily, so there is only one
body in memory at the same time.
Headers should probably be requested and fetched outside a MimeMessage.
(few headers, many messages, one query)
+1
Please consider current Torque implementation as a prototype. At the
moment I'm not even sure if we should work with MimeMessages, as its
concept is based too much on lazy-loading
i've been wondering the same :-)
getImapMailboxSession couples MailboxManager to the protocol. so,
there's nothing to stop a more intimate relationship between the
parsing layer and the data store integration code.
The current blocker is the FetchCommand implementation as it was written
with an in-memory-store. It examines the MimeMessage completely, even if
only flags are fetched.
New FetchCommand implementation is on the way. :-)
cool :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
