james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Daring" <cog...@chello.at>
Subject Re: LocalDelivery and Delivered-To
Date Sun, 09 Nov 2003 21:28:30 GMT
> > 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.

Thats correct. Therefor I use an additional header-list in
which is also written to the OutputStream in the writeTo-methods.

> > 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?

Default behavior of the matcher and recipient sets is recipientconsumption.
That means
if there are recipients the matcher doesnt catch this recipients are the new
ones for
the mail in the next mailet. If I add a tag in a mailet (in the config-file)
<consumeRecipients>false</consumeRecipients> the recipients of the next
matcher-mailet pair
is the same as the actuall one. I also find it helpful to introduce some
kind of composition behavior
like having a list in the MailImpl-object that contains all the mailetnames
that should ignore this mail.
So each Mailet asks this list if its name is in it and if so the Mailet does
nothing. But this is only for my
special needs as I have up to 4 rounds of the same mail in the pipeline; a
case where state-handling gets
a bit tricky.

> > 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
> size?  Interesting idea.

Yes thats true, since Ive given up plans storing large mails in the db
because of the db specific
code thats needed for this task.

> > 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
> but has other implications.

Another cache I use is a inboxrepository cache for the pop3handler. You have
mentioned earlier that
the inboxrepositories are created for each user and are hold in a
collection. You have declared this as a bug.
(A quick and dirty fix would be a WeakHashMap)

By the way I remember that I had a bad feeling regarding the errorhandling
in LinearProcessor. I am not sure if the sender
of a mail gets an error message if the db fails.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message