james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: LocalDelivery and Delivered-To
Date Sun, 09 Nov 2003 20:30:04 GMT
> > 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message