This looks like a fine thing to do. It is similar in concept to the outgoing mail spool, and makes a lot of sense. This is much the way that James is meant to be extended, and if your patch is backwards compatible, submit it.
Make sure that you fully solve the processor name thing though, you don't want to have to deal with James users when SPAM's and ERROR's get handled in the wrong place, and toProcessor _appears_ not to work. d. On 24/05/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'd like to know your opinion on a simple patch I applyed to james3 to solve > this problem: > > I've a medium complexity james configuration with 10 processors and 40 spool > threads. One of the mailet in one of the processor is memory-consuming so I > would like to avoid 40 threads to run in that mailet at the same time. I > would like to have a maximum of 5 threads working on that processor at the > same time. > > I evaluated many possible solutions and finally come to this: > > I added a new configuration (backward compatible) option for the > spool-manager called spoolrepository: if you don't specify a custom > spoolrepository it will use the inboundSpoolmanager from the binded > mailstore. If you configure a different spoolrepository it will use this > different spoolrepository. > > I also created a ToSpoolRepository mailet that is identical to ToRepository > but request a SPOOL repository instead of MAIL repository. > > Then I added a new block to my assembly with a second spoolmanager named > "dedicatedspoolmanager" and added a new configuration to the config.xml for > this. > > <spoolmanager> > <threads> 40 </threads> > <processor name="root"> > .... > </processor> > > <processor name="dedicatedprocessor"> > <mailet match="All" class="ToSpoolRepository"> > <repositoryPath>db://maildb/spool/dedicatedspool</repositoryPath> > </mailet> > </processor> > > <processor name="nextprocessor"> > .... > </processor> > </spoolmanager> > > <dedicatedspoolmanager> > <threads> 5 </threads> > > <spoolRepository> > <repository destinationURL="db://maildb/spool/dedicatedspool" > type="SPOOL"/> > </spoolRepository> > > <processor name="dedicatedprocessor"> > > </processor> > > <processor name="nextprocessor"> > <mailet match="All" class="ToSpoolRepository"> > <repositoryPath>db://maildb/spool/spool</repositoryPath> > </mailet> > </processor> > </dedicatedspoolmanager> > > I think I will also add to ToSpoolRepository the ability to set the > processor (State) to use in the new repository: currently it works by > "sharing" processor names. > > What do you think? > > The spoolmanager patch is 5 lines of codes and fully backward compatible: is > a feature (the spoolmanager patch + the ToSpoolRepository mailet) like this > a committable change or is it too specific behaviour to be included in the > default core? > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
