> 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: http://java.sun.com/products/javamail/1.3/docs/javadocs/javax/mail/internet/ MimeMessage.html#MimeMessage(javax.mail.Session,%20java.io.InputStream) > 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? > can you point out where the thread pool finally changes have been done. > Can't see from the diffs and how this is a problem with current system. finally { Thread.currentThread().interrupted(); } Technically, Thread.interrupted() would suffice; currentThread() is redundant. > C. Scheduler leak. This can be addressed in different ways. It is being > disscussed separately. let us keep the memory leak for thread pool and > MimeMessageInputStream separate. What do you mean by this? The ThreadPool and MimeMessageInputStream changes *are* independent of the Watchdog / Scheduler issue. --- Noel -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
