There seem to be 3 problems that are being addressed.

A. Problem with MimeMessageInputStreamSource.java. current finalize may not
fix memory issues if the system is under a lot of stress.
Would this be a better fix given that data is already being read in memory ?

Index: MimeMessageInputStreamSource.java
===================================================================
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/core/MimeMessageInputStrea
mSource.java,v
retrieving revision 1.8
diff -u -r1.8 MimeMessageInputStreamSource.java
--- MimeMessageInputStreamSource.java 3 Sep 2002 16:52:16 -0000 1.8
+++ MimeMessageInputStreamSource.java 19 Oct 2002 21:55:55 -0000
@@ -24,9 +24,9 @@
 public class MimeMessageInputStreamSource extends MimeMessageSource {

     /**
-     * A temporary file used to hold the message stream
+     * message stream
      */
-    File file = null;
+    byte[] msgbytes = null;

     /**
      * The full path of the temporary file
@@ -46,32 +46,19 @@
      */
     public MimeMessageInputStreamSource(String key, InputStream in)
             throws MessagingException {
-        //We want to immediately read this into a temporary file
-        //Create a temp file and channel the input stream into it
-        OutputStream fout = null;
         try {
-            file = File.createTempFile(key, ".m64");
-            fout = new BufferedOutputStream(new FileOutputStream(file));
+            ByteArrayOutputStream baout = new ByteArrayOutputStream();
             int b = -1;
-            while ((b = in.read()) != -1) {
-                fout.write(b);
+            byte[] ba = new byte[1024];
+            while ((b = in.read(ba)) != -1) {
+                baout.write(ba,0,b);
             }
-            fout.flush();
-            file.deleteOnExit();
-
-            sourceId = file.getCanonicalPath();
+            msgbytes = baout.toByteArray();
+            sourceId = key;
         } catch (IOException ioe) {
             throw new MessagingException("Unable to retrieve the data: " +
ioe.getMessage(), ioe);
         } finally {
             try {
-                if (fout != null) {
-                    fout.close();
-                }
-            } catch (IOException ioe) {
-                // Ignored - logging unavailable to log this non-fatal
error.
-            }
-
-            try {
                 if (in != null) {
                     in.close();
                 }
@@ -96,7 +83,7 @@
      * @return a <code>BufferedInputStream</code> containing the data
      */
     public synchronized InputStream getInputStream() throws IOException {
-        return new BufferedInputStream(new FileInputStream(file));
+        return new ByteArrayInputStream(msgbytes);
     }

     /**
@@ -107,22 +94,6 @@
      * @throws IOException if an error is encoutered while computing the
size of the message
      */
     public long getMessageSize() throws IOException {
-        return file.length();
-    }
-
-    /**
-     * <p>Finalizer that closes and deletes the temp file.  Very bad.</p>
-     * <p>TODO: Should be replaced with a more robust cleanup mechanism</p>
-     *
-     */
-    public void finalize() {
-        try {
-            if (file != null && file.exists()) {
-                file.delete();
-            }
-        } catch (Exception e) {
-            //ignore
-        }
-        file = null;
+        return msgbytes.length;
     }
 }


B. Problem with ThreadManager. I think it is best to replace scratchpad
thread pool with the one from util concurrent library. Also not 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.

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.

Harmeet


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>

Reply via email to