Ok, that's clear, we must remove calls to that constructor from our
code, and we should use new MimeMessage(Session s, InputStream is).
Furthermore we should pass a SharedInputStream to that constructor.
How is it done technically? How to do the conversion from
MimeMessage(MimeMessage source) to MimeMessage(Session s, InputStream is) ?
This is what we're trying to find out.
You suggested to use the existing repository instead, which is a good
idea. But two questions:
1. how do I locate the message in the repository form the MimeMessage
"source"?
I think this is not possible. You can get the source starting from the
Mail object in the repository but not viceversa.
Why do you need that?
I wanted to use it in a subclass_of_MimeMessage that would override that
constructor and there, in that overriding constructor, it would use the
message in the repository in order to construct the new
subclass_of_MimeMessage. This is instead of using a temporary file like
I did (or a byte array like in the original MimeMessage constructor).
If it isn't possible now, it could be made possible in a subclass by
putting a key field in that subclass, that would contain data that would
serve as a reference to that message in the repository. Then in places
where James constructs a new MimeMessage from the repository, it would
instead construct the subclass, and then add to it the key that
references that message in the repository. This way when that object
would be passed in the future to such a constructor, it would contain a
reference to its place in the repository, and so it could be constructed
from the repository.
This is already done by the MimeMessageWrapper/MimeMessageSource combo.
I think that we simply should try to use them well and to make them use
SharedInputStreams.
2. Does every MimeMessage exist in the repository?
[...]
So I understand that some times it may happen that there would be a big
message not in the repository. [...]
MimeMessages created from James will have a source and we can control
it. If an user create its own mailet and uses the wrong constructor we
can't do anything about it: his data will be in memory.
Yes, it looks like a good idea. There is already in javaMail 1.3.2 a
com.sun.mail.util.SharedFileInputStream class. Version 1.4 has also a
javax.mail.util.SharedFileInputStream.
As a test we can use the SharedFileInputStream from 1.4 in the hope that
sun will release 1.4 final soon (and that it will work better than 1.3.3).
Another optimization we could apply would be to skip the temporary file
created by the SMTP server when receiving new files: we always create a
temp file for the incoming stream and after the SMTP session is finished
we send the message to the spoolrepository (copying all the temp file
content to db or to a new file).
The first big problem of all this interesting optimizations is that they
are very delicate and difficult to test and it's so easy to break
something (eg: see the 60 seconds delay issue I fixed yesterday). BTW
this discussion is interesting and the current solution is probably
optimistic and we'll encounter much more problems trying to implement them.
The second big problem is that it doesn't matter wether we do all of
this optimizations every time a mailet will try to alter the message
body via the javamail api the message is fully loaded in ram.
The third problem is the time, but this is a first important step, and I
hope to find the time to try at least a few of the thing we described.
PS: are you subscribed to the server-dev list? I still add you in CC
because I'm not sure about it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
