Joachim Draeger 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.
I did a lot of tests in this regard for streaming in-out blobs to the dbs.
I've been succesfull with Oracle 10 all updated both in reading and
writing. I've also had success with mysql 5 and latest connector beta
(few months ago). I failed with derby, mysql3 and oracle 9 with his
drivers. I had partial success with mysql 4 (new drivers) and oracle9
(new drivers). I this that the latest derby should work (when used in
embedded mode and not in network mode). I remember that mysql needed
some hack to work fine.
The streaming while *reading* code is already present in trunk (you only
have to change the "inMemorySizeLimit" configuration in your config.xml)
We had weird issues while testing it, but in my TODO list there is a
note about testing it more.
The writing code is still on my HD because it had much more issues and
we was still testing the reading code.
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.
You're right, this is an issue to take into consideration and I never
thought about it before: thank you for pointing this out!
One improvement can be loading the body lazily, so there is only one
body in memory at the same time.
This should be already managed by the
MimeMessageWrapper/MimeMessageSource stuff: maybe TorqueMimeMessage can
be refactored to use a MimeMessageWrapper and provide a
TorqueMimeMessageSource instead.
Headers should probably be requested and fetched outside a MimeMessage.
(few headers, many messages, one query)
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.
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. :-)
Joachim
Cool!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
