> What are some strategies for dealing with long running mailets?
The spooler does use multiple threads, but there is a fixed size thread
pool. And you don't need parallel execution of lots of personalizers.
For the timing being, I would recommend modeling it as a cross between
RemoteDelivery and ToProcessor. You'll take the message out of the spool,
put it on an internal work queue, process it on a separate worker thread,
and then post it back into the pipeline in a new processor [*but see below*]
It might be a good idea if we had a suitable abstract class for that
behavior, so that people don't roll too many of their own solutions, and so
that we can optimize that functionality in James v3, when we should have a
new spooler.
Personally, I think that there is a good case for making a custom
RemoteDelivery mailet that embeds customization. That way you don't
re-insert 1000s of messages. You just personalize them on the way out the
door.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
