----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> > A. Problem with MimeMessageInputStreamSource.java > > Would this be a better fix given that data is already being read in memory > ? > > However it isn't, and such a solution would not scale for large messages. > What makes you think otherwise? You also commented to me about MimeMessage > loading the body into memory. Please see the javadocs for that class; > specifically the constructor used: Yes I made a mistake based on dated knowledge. Serge corrected me. I can see the patch a bit better now. > > > B. Problem with ThreadManager. I think it is best to replace scratchpad > > thread pool with the one from util concurrent library. > > What "scratchpad thread pool"? James uses Thread pool management provided > by Excalibur. Are you proposing that we replace their thread management > code with new classes derived from Doug Lea's library? I think we should do that. Replacing thread pool abstraction should be straight forward. I never understood why the Avalon folks created concurrent packages when there was a nice standard threading library around. There have almost always been threading issues in Avalon. There was talk of getting Doug Lea library under Apache, but for some reason that never happened. Thread pool code was part of scratchpad where the Avalon folks had useful but not fully qualified code. It looks like it has been moved to not sure where. > > What do you mean by this? The ThreadPool and MimeMessageInputStream changes > *are* independent of the Watchdog / Scheduler issue. Had to wade through a alot of code, so could not easily separate. Thanks for pointing out. Harmeet -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
