Serge Knystautas wrote:
>
> Charles,
>
> I was actually just working on some other optimizations that were changing
> how MailImpl handles messages. Aside from some optimizations specific to
> the database mail repository, I had begun to work towards the change you had
> made.
>
> I believe the way the original version intended to work was to allow the
> input streams to be resettable and to not read in the MimeMessage until you
> accessed that MimeMessage. This was to avoid the parse time and memory
> usage of MimeMessage. Unfortunately it has created this difficult to track
> down stream open errors and also isn't very efficient in preventing James
> from parsing a MimeMessage.
>
> Having MailImpl always parse the InputStream into a MimeMessage should fix
> the stream open problem (I'm almost certain). However, I still wanted to
> avoid parsing MimeMessage if possible, so this was how I was going to make
> this happen.
>
> I created a JamesMimeMessage class that extends MimeMessage. It is created
> by passing an inputstream which it will use to create a MimeMessage that it
> will wrap. All methods on JamesMimeMessage will call the same method on the
> wrapped message. The trick is though that it will not instantiate the
> MimeMessage until you do call one of its methods. Also, it keeps track of
> whether you modify the message so James could skip saving an unchanged
> message.
>
> The second thing was to create a new InputStream. This new inputstream
> would get constructed by passing whatever parameters you need to get to the
> underlying inputstream. For instance, in the AvalonMailRepository, you
> would use a AvalonMimeMessageInputStream and pass it the StreamRepository
> object (sr) and the message key (key). Your code would go from...
>
> mc.setMessage(sr.get(key));
>
> to...
>
> mc.setMessage(new AvalonMimeMessageInputStream(sr, key));
>
> The AvalonMimeMessageInputStream would not actually open a connection to the
> streamrepository until you tried to read from the stream. When you pass
> this into the JamesMimeMessage object, then you no longer open a connection
> to that file until someone calls a method on that MimeMessage.
>
> This might sound a bit confusing, but I think it's a better approach to not
> reading and instantiating MimeMessages all the time, which has created the
> file stream problem. Your patch was going to be my next step, so MailImpl
> never kept just the inputstream and handed off responsibility of knowing
> when to instantiate the MimeMessage and that stream to JamesMimeMessage and
> the new input stream.
>
> I'm making changes to 1.2 tree for now and once everything is working
> reliably, I'll commit my changes.
>
The question is whether the performance gains are worth the additional
complication.
I can see why one might want to avoid parsing an InputStream into a
MimeMessage object.
At the same time, this system creates more objects, so at some
proportion, the benefit of never parsing streams for some mails is going
to be overwhelmed by the additional objects created for all messages.
I suspect that for simple SMTP and POP3 stuff, avoiding parsing makes
sense. However, for IMAP and more complex mailets/matchers, avoiding
object creation (and simplicity) makes sense.
Let's see what feedback we get on your fixes (which are available in
cvs).
Charles
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
