> > Send an e-mail to multiple local recipients. Each time you call
> > addHeader, you should be adding a new Delivered-To header to the
> > message, which means that you will be accumulating additional
> > headers. If you only have one local recipient, you'll never
> > notice the difference.
> Yes, I have taken that into account and thats also why I have to
> remove the header after leaving LocalDelivery
You would have to remove it within the loop, since that loop is delivering
to all of the local recipients associated with the message.
> > The call to saveChanges is required by the JavaMail
> > specification, but we end up short-circuiting it,
> > which is the whole purpose for our updateHeaders()
> > method.
> Different approach same result. But my message isnt loaded into memory.
There is no question that the MimeMessage handling needs to be done
differently in that code and a couple of others. I've said that since it
was done, but haven't had the time to fix it. That is something I intend to
do shortly.
> > The only place we create a duplicate in LinearProcessor
> > is where we have two paths for a Mail to take after a
> > matcher. IFF there are recipients for both paths, a
> > duplicate is made of the Mail, which is just the processing
> > envelope not the message contents, to track the dual paths.
> Yes, the situation when theres a mix of recipients. This
> duplication was eliminated. Not a big change but quicker.
So what are you doing to track the multiple recipient sets, whose lifetime
is not processor scoped?
> I added an additional tag in my config-file setting the max
> messagesize of mails I dont want to store in the DB.
So you automatically shift between db and file store based upon the message
size? Interesting idea.
> My James version im working with is quite different but
> > I dont think it has any affect on this peace of code.
>
> Do you want to submit any of your changes for consideration?
> A message cache for/in the MailRepositories also improved
> the performance. Also a cache for the PreparedStatements.
The latter should be handled by DBCP. The former is something we could do,
but has other implications.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
