Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.3.0
    • Component/s: James Core
    • Labels:
      None

      Description

      MailImpl#writeContentTo(OutputStream, int) (used by POP3 TOP) does not close the input stream acquired from its MimeMessage. MimeMessage#getInputStream is a PipedInputStream and has a thread running on its behalf. Thus, MailImpl leaks a thread per
      message TOPed.

      Fix:
      in = message.getInputStream();
      try {
      ...
      } finally {
      in.close
      }

        Activity

        Hide
        bago Stefano Bagnara added a comment -

        Maybe we have the same problem in AbstractRedirect, too.

        Show
        bago Stefano Bagnara added a comment - Maybe we have the same problem in AbstractRedirect, too.
        Hide
        bago Stefano Bagnara added a comment -

        the method was moved to POP3Handler and fixed.
        AbstractRedirect fixed too (try/catch/finally was in the wrong place)

        Show
        bago Stefano Bagnara added a comment - the method was moved to POP3Handler and fixed. AbstractRedirect fixed too (try/catch/finally was in the wrong place)
        Hide
        mernst Matthias Ernst added a comment -

        + BufferedReader br = null;
        + if (message != null) {
        + try {
        + br = new BufferedReader(new InputStreamReader(message.getInputStream()));
        + while (lines-- > 0) {
        + if ((line = br.readLine()) == null)

        { + break; + }

        + line += "\r\n";
        + out.write(line.getBytes());
        + }
        + } finally {
        + if (br != null)

        { + br.close(); + }
        + }
        + } else { + throw new MessagingException("No message set for this MailImpl."); + }

        I've seen this so often. Why such complicated cleanup? You should always start the "try" AFTER you allocate the resource/acquire the lock/... Then the scope of the variable is right and your don't need to check whether it actually happened.

        + if (message != null) {
        + BufferedReader br = new BufferedReader(new InputStreamReader(message.getInputStream()));
        + try {
        + while (lines-- > 0) {
        + if ((line = br.readLine()) == null) { + break; + }
        + line += "\r\n";
        + out.write(line.getBytes());
        + }
        + } finally {+ br.close();+ }

        + } else

        { + throw new MessagingException("No message set for this MailImpl."); + }

        Matthias

        Show
        mernst Matthias Ernst added a comment - + BufferedReader br = null; + if (message != null) { + try { + br = new BufferedReader(new InputStreamReader(message.getInputStream())); + while (lines-- > 0) { + if ((line = br.readLine()) == null) { + break; + } + line += "\r\n"; + out.write(line.getBytes()); + } + } finally { + if (br != null) { + br.close(); + } + } + } else { + throw new MessagingException("No message set for this MailImpl."); + } I've seen this so often. Why such complicated cleanup? You should always start the "try" AFTER you allocate the resource/acquire the lock/... Then the scope of the variable is right and your don't need to check whether it actually happened. + if (message != null) { + BufferedReader br = new BufferedReader(new InputStreamReader(message.getInputStream())); + try { + while (lines-- > 0) { + if ((line = br.readLine()) == null) { + break; + } + line += "\r\n"; + out.write(line.getBytes()); + } + } finally {+ br.close();+ } + } else { + throw new MessagingException("No message set for this MailImpl."); + } Matthias
        Hide
        ralfhauser Ralf Hauser added a comment -

        We just ran into this problem too during a load test we did for pop3+SSL (we extended JMeter to do so: http://issues.apache.org/bugzilla/show_bug.cgi?id=38384).

        When will the new release come out officially where that is fixed?

        Just FYI what it looks when your JVM is dying:
        For each TOP, you will have a starving thread haning around (below if the concerned message had an attachment - not sure whether the error also occurs for simple mails...).

        "DataHandler.getInputStream" daemon prio=1 tid=0x0000002b0365a1e0 nid=0x19e3 in Object.wait() [0x0000002b29c03000..0x0000002b29c04350]
        at java.lang.Object.wait(Native Method)
        at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:204)
        at java.io.PipedInputStream.receive(PipedInputStream.java:136)

        • locked <0x0000002af7d7fe20> (a java.io.PipedInputStream)
          at java.io.PipedOutputStream.write(PipedOutputStream.java:103)
          at com.sun.mail.util.QPEncoderStream.output(QPEncoderStream.java:162)
          at com.sun.mail.util.QPEncoderStream.write(QPEncoderStream.java:109)
          at com.sun.mail.util.QPEncoderStream.write(QPEncoderStream.java:64)
          at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
          at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404)
          at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
          at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
        • locked <0x0000002af7d80d28> (a java.io.OutputStreamWriter)
          at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
          at com.sun.mail.handlers.text_plain.writeTo(text_plain.java:127)
          at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:839)
          at javax.activation.DataHandler.writeTo(DataHandler.java:295)
          at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1206)
          at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:707)
          at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:256)
          at com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:67)
          at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:839)
          at javax.activation.DataHandler$1.run(DataHandler.java:248)
          at java.lang.Thread.run(Thread.java:595)
        Show
        ralfhauser Ralf Hauser added a comment - We just ran into this problem too during a load test we did for pop3+SSL (we extended JMeter to do so: http://issues.apache.org/bugzilla/show_bug.cgi?id=38384 ). When will the new release come out officially where that is fixed? Just FYI what it looks when your JVM is dying: For each TOP, you will have a starving thread haning around (below if the concerned message had an attachment - not sure whether the error also occurs for simple mails...). "DataHandler.getInputStream" daemon prio=1 tid=0x0000002b0365a1e0 nid=0x19e3 in Object.wait() [0x0000002b29c03000..0x0000002b29c04350] at java.lang.Object.wait(Native Method) at java.io.PipedInputStream.awaitSpace(PipedInputStream.java:204) at java.io.PipedInputStream.receive(PipedInputStream.java:136) locked <0x0000002af7d7fe20> (a java.io.PipedInputStream) at java.io.PipedOutputStream.write(PipedOutputStream.java:103) at com.sun.mail.util.QPEncoderStream.output(QPEncoderStream.java:162) at com.sun.mail.util.QPEncoderStream.write(QPEncoderStream.java:109) at com.sun.mail.util.QPEncoderStream.write(QPEncoderStream.java:64) at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336) at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404) at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) locked <0x0000002af7d80d28> (a java.io.OutputStreamWriter) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at com.sun.mail.handlers.text_plain.writeTo(text_plain.java:127) at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:839) at javax.activation.DataHandler.writeTo(DataHandler.java:295) at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1206) at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:707) at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:256) at com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:67) at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:839) at javax.activation.DataHandler$1.run(DataHandler.java:248) at java.lang.Thread.run(Thread.java:595)
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            bago Stefano Bagnara
            Reporter:
            mernst Matthias Ernst
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development