Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53305

javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed;

    Details

    • Type: Bug
    • Status: In Progress (View Workflow)
    • Priority: Critical
    • Resolution: Unresolved
    • Component/s: mailer-plugin
    • Labels:
      None
    • Environment:
      Docker image jenkins/jenkins:2.121.2
    • Similar Issues:

      Description

      Hello

      • Jenkins 2.121.2 (official Docker image)
      • Mailer Plugin 1.21

       

      Sometimes pipelines in Jenkins fails with next exception:

       

      javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed; 
       boundary="----=_Part_232_854096954.1535491539067"
       at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:896)
       at javax.activation.DataHandler.writeTo(DataHandler.java:317)
       at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1476)
       at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1772)
       at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1099)
      Caused: javax.mail.MessagingException: IOException while sending message;
       nested exception is:
       javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed; 
       boundary="----=_Part_232_854096954.1535491539067"
       at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1141)
       at javax.mail.Transport.send0(Transport.java:195)
       at javax.mail.Transport.send(Transport.java:124)
       at org.jenkinsci.plugins.workflow.steps.MailStep$MailStepExecution.run(MailStep.java:142)
       at org.jenkinsci.plugins.workflow.steps.MailStep$MailStepExecution.run(MailStep.java:128)
       at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1$1.call(SynchronousNonBlockingStepExecution.java:50)
       at hudson.security.ACL.impersonate(ACL.java:290)
       at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution$1.run(SynchronousNonBlockingStepExecution.java:47)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
       at java.lang.Thread.run(Thread.java:748)
      

       

      Example of pipeline:

      node {
         mail(to: "xxx@example.com", subject: "test", body: "test")
      }
      

       

      Settings:

      • SMTP server: mail.example.com
      • Default user e-mail suffix: @example.com

       

      Restart of Jenkins temporary solve the issue.

       

      Please fix the bug.

      Thank you

        Attachments

          Activity

          Hide
          agentgonzo Steve Arch added a comment - - edited

          Mykola Ulianytskyi - we're having the same behaviour on our build platform - maybe we can share some details to diagnose the problem. I'm having trouble re-creating it locally on my dev machine and finding it hard to trace?

          Are you running on build agents, or building on the master itself? Was this a fresh install of the docker image or have you got any other plugins installed too? How often do you get the issues?

           

          I'm not seeing it locally on a fresh jenkins install, but we see it ~5% of the time on our long-running jobs on our CI system. We run one-shot agents so hard to trace exactly what the infrastructure is that it fails on when it fails to trace the issue. As it's our main CI system, attaching a debugger isn't possible

          Show
          agentgonzo Steve Arch added a comment - - edited Mykola Ulianytskyi - we're having the same behaviour on our build platform - maybe we can share some details to diagnose the problem. I'm having trouble re-creating it locally on my dev machine and finding it hard to trace? Are you running on build agents, or building on the master itself? Was this a fresh install of the docker image or have you got any other plugins installed too? How often do you get the issues?   I'm not seeing it locally on a fresh jenkins install, but we see it ~5% of the time on our long-running jobs on our CI system. We run one-shot agents so hard to trace exactly what the infrastructure is that it fails on when it fails to trace the issue. As it's our main CI system, attaching a debugger isn't possible
          Hide
          agentgonzo Steve Arch added a comment - - edited

          It seems to be an issue with the context class loader. By running lots of jobs, I could see that the thread's current class loader was null when the problem occurred.

          I can re-create the issue exactly by running Thread.currentThread().setContextClassLoader(null); just before the call to Transport.send(mimeMessage);

          Still investigating...

          Show
          agentgonzo Steve Arch added a comment - - edited It seems to be an issue with the context class loader. By running lots of jobs, I could see that the thread's current class loader was null  when the problem occurred. I can re-create the issue exactly by running Thread.currentThread().setContextClassLoader(null);  just before the call to Transport.send(mimeMessage); Still investigating...
          Hide
          agentgonzo Steve Arch added a comment -

          I've been trying to track this down, but have run out of time. It definitely seems to be the issue mentioned above that the contextClassLoader is set to null, but where this is getting set to null I don't know. I've traced this back up the stack and all the threads that it's operating on are spawned by the pipeline plugins (when a thread spawns another thread, the contextClassLoader is inherited from the parent). I could see that the threads in the pipeline plugins had the contextClassLoader set to `null` sometimes, but I couldn't track down where in its myriads of threads and threadpools the root of the issue where it was setting the contextClassLoader to null that triggered this issue (there are lots of instances where it does set it to null, but a lot of those are 'valid' given the context. 

          Unfortunately, I can only see this issue on our build infrastructure which is hard to debug (attaching a debugger will basically lock up the Jenkins instance) as there is so much going on. Mykola Ulianytskyi - are you able to recreate the issues in a fresh/newly installed instance that I could run locally to get a better handle on what's going on? Remote debugging isn't working for me.

          What I was attempting to do was to launch Jenkins with debug flags and attach a debugger to Thread.setContextClassLoader and get the debugger to break if it is setting it no null. As I said, this happened so much it was hard to identify where this was doing it 'wrongly'. Maybe Mykola Ulianytskyi could have some luck tracing it down?

          Some possibly useful stack traces I got are attached if they are useful to anyone. I got lots where it was in the sun.net.www.http package, but these seem valid given the comments here and given the fact that that thread is not re-used.

          Show
          agentgonzo Steve Arch added a comment - I've been trying to track this down, but have run out of time. It definitely seems to be the issue mentioned above that the contextClassLoader is set to null, but where this is getting set to null I don't know. I've traced this back up the stack and all the threads that it's operating on are spawned by the pipeline plugins (when a thread spawns another thread, the contextClassLoader is inherited from the parent). I could see that the threads in the pipeline plugins had the contextClassLoader set to `null` sometimes , but I couldn't track down where in its myriads of threads and threadpools the root of the issue where it was setting the contextClassLoader to null that triggered this issue (there are lots of instances where it does set it to null, but a lot of those are 'valid' given the context.  Unfortunately, I can only see this issue on our build infrastructure which is hard to debug (attaching a debugger will basically lock up the Jenkins instance) as there is so much going on. Mykola Ulianytskyi - are you able to recreate the issues in a fresh/newly installed instance that I could run locally to get a better handle on what's going on? Remote debugging isn't working for me. What I was attempting to do was to launch Jenkins with debug flags and attach a debugger to Thread.setContextClassLoader and get the debugger to break if it is setting it no null . As I said, this happened so much it was hard to identify where this was doing it 'wrongly'. Maybe Mykola Ulianytskyi could have some luck tracing it down? Some possibly useful stack traces I got are attached if they are useful to anyone. I got lots where it was in the sun.net.www.http package, but these seem valid given the comments here and given the fact that that thread is not re-used.
          Hide
          agentgonzo Steve Arch added a comment -

          As a workaround, I have raised https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/69 as a workaround, so you may find a local build of this deployed to your Jenkins instance will be a workaround for the issue (it's not an actual fix). It detects if the contextClassLoader is null before attempting to send the email, and then sets it to the default one in Jenkins.

          Show
          agentgonzo Steve Arch added a comment - As a workaround, I have raised https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/69  as a workaround, so you may find a local build of this deployed to your Jenkins instance will be a workaround for the issue (it's not an actual fix). It detects if the contextClassLoader is null before attempting to send the email, and then sets it to the default one in Jenkins.
          Hide
          dnusbaum Devin Nusbaum added a comment -

          I filed a PR that would address one potential way this could happen in a slightly more general way than the workflow-basic-steps workaround in https://github.com/jenkinsci/workflow-step-api-plugin/pull/39, but I still do not understand the actual root cause.

          Show
          dnusbaum Devin Nusbaum added a comment - I filed a PR that would address one potential way this could happen in a slightly more general way than the workflow-basic-steps workaround in https://github.com/jenkinsci/workflow-step-api-plugin/pull/39,  but I still do not understand the actual root cause.
          Hide
          dnusbaum Devin Nusbaum added a comment -

          I would be very interested to know if anyone who is experiencing this problem still sees it in after updating to version 2.17 of the Pipeline Step API Plugin, which should be available from the update center in a few hours.

          Show
          dnusbaum Devin Nusbaum added a comment - I would be very interested to know if anyone who is experiencing this problem still sees it in after updating to version 2.17 of the Pipeline Step API Plugin, which should be available from the update center in a few hours.
          Hide
          cleclerc Cyrille Le Clerc added a comment -

          Devin Nusbaum I am seeing the bug at the moment with the Pipeline Step API 2.16. I'll try to bump soon.

          Show
          cleclerc Cyrille Le Clerc added a comment - Devin Nusbaum I am seeing the bug at the moment with the Pipeline Step API 2.16. I'll try to bump soon.
          Hide
          inge4pres Francesco Gualazzi added a comment - - edited

          Mailer plugin v 1.22 but same LTS version (2.121.3).

          A workaround we found is to add the MIME types explicitly, like so

          import javax.activation.MailcapCommandMap;
          import javax.activation.CommandMap;
          
          @NonCPS
          def setupMail(){
              MailcapCommandMap mc = (MailcapCommandMap) CommandMap.getDefaultCommandMap();
              mc.addMailcap("text/html;; x-java-content-handler=com.sun.mail.handlers.text_html");
              mc.addMailcap("text/xml;; x-java-content-handler=com.sun.mail.handlers.text_xml");
              mc.addMailcap("text/plain;; x-java-content-handler=com.sun.mail.handlers.text_plain");
              mc.addMailcap("multipart/*;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed");
              mc.addMailcap("message/rfc822;; x-java-content- handler=com.sun.mail.handlers.message_rfc822");
          }
          
          node {
              setupMail()
              mail(   from: 'jenkins@co.com', 
                      replyTo: 'me@co.com', 
                      to: someone@co.com,
                      subject: "Hi there MIME",  
                      body: "It Works!")
          }
          

          Hope this helps

          Show
          inge4pres Francesco Gualazzi added a comment - - edited Mailer plugin v 1.22 but same LTS version (2.121.3). A workaround we found is to add the MIME types explicitly, like so import javax.activation.MailcapCommandMap; import javax.activation.CommandMap; @NonCPS def setupMail(){ MailcapCommandMap mc = (MailcapCommandMap) CommandMap.getDefaultCommandMap(); mc.addMailcap( "text/html;; x-java-content-handler=com.sun.mail.handlers.text_html" ); mc.addMailcap( "text/xml;; x-java-content-handler=com.sun.mail.handlers.text_xml" ); mc.addMailcap( "text/plain;; x-java-content-handler=com.sun.mail.handlers.text_plain" ); mc.addMailcap( "multipart/*;; x-java-content-handler=com.sun.mail.handlers.multipart_mixed" ); mc.addMailcap( "message/rfc822;; x-java-content- handler=com.sun.mail.handlers.message_rfc822" ); } node { setupMail() mail( from: 'jenkins@co.com' , replyTo: 'me@co.com' , to: someone@co.com, subject: "Hi there MIME" , body: "It Works!" ) } Hope this helps

            People

            • Assignee:
              capf Carsten Pfeiffer
              Reporter:
              lystor Mykola Ulianytskyi
            • Votes:
              7 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated: