Hi all,
Just spent 2 days studying javamail sourcecode and how James
creates/uses MimeMessages and I found that current javamail MimeMessage
(i worked on 1.3.2) has many protected methods and expose very much of
its internal behaviour.
Furthermore, you, perhaps, rememeber a long thread about the use of
SharedInputStream when creating new MimeMessages to avoid Javamail to
load the full message in memory.
I started writing tests for the MimeMessage and its various flavor
(depending on the constractor used) and for our own Wrappers:
MimeMessageWrapper/MimeMessageCopyOnWriteProxy.
I then found that most of the MimeMessageWrapper operations were the
exact "copy" of the MimeMessage behaviour and I though that I should
have tried to drop the "wrapping/delegation" behaviour in favor of a
simple extension.
This way it was simpler to define when the message is needed and I've
been able to avoid the message loading for most header operations
(previously needed). Furthermore, with this new approach, we don't need
to wrap all the MimeMessage methods and we'll have better compatibility
for the future.
I then changed every source of our messages to return SharedInputStreams
(starting from the Avalon stream repository) and I wrote a
SharedSequenceInputStream to handle sequence of sharedInputStreams to be
seen as a SharedInputStream.
The result is that all the tests still passes and that I removed a full
layer.
I then started working on the JDBCRepositories/MimeMessageJDBCSource to
remove the current ByteArray usage in favor of blob streaming and tested
it using latest Connecto/J drivers against a Mysql 4 db: the good news
is that this combo also handle messages bigger than the mysql
packet_size and the memory usage is at most the packet_size (the
connector/j allocate a buffer sized according to that parameter).
I made this behaviour optional by adding a new "getBody" option
(useBinaryStream) to the dbOptions in sqlResources so that testers could
try this feature over different dbs and provide feedback.
I think this could be a big improvement for performance and reduce the
memory footprint but I also think that this is a critical change that
will probably add more delay to a stable release.
My personal vote goes to commit the new code so that other
committers/developers could review the changes but I would like to know
what do you think about this, before moving.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
