Stefano Bagnara schrieb: > 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.
Just a quick note.. I use the current streaming code without problems at the moment with mysql 5 + connector. Maybe we allready fix the issuses when workin on other bugs ;-) > >> 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. +1 This makes really sense. > >> 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 > Im looking forward to this new code. Thx for all your work Joachim. bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
