> > 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 MimeMessageWrapper 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) like <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 message > 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 do, > 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. M --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
