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

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

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • mailer-plugin
    • None
    • Docker image jenkins/jenkins:2.121.2

      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

          [JENKINS-53305] javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed;

          Steve Arch added a comment - - edited

          lystor - 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

          Steve Arch added a comment - - edited lystor - 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

          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...

          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...

          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. lystor - 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 lystor 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.

          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. lystor - 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 lystor 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.

          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.

          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.

          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.

          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.

          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.

          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.

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

          Cyrille Le Clerc added a comment - dnusbaum I am seeing the bug at the moment with the Pipeline Step API 2.16. I'll try to bump soon.

          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

          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

          Greg Allen added a comment -

          We have been using the workaround above provided by inge4pres .  However, we just upgraded to 2.361.1 and CommandMap.getDefaultCommandMap() now returns a DelegatingCommandMap object (https://javadoc.jenkins-ci.org/plugin/jakarta-mail-api/io/jenkins/plugins/jakarta/activation/DelegatingCommandMap.html) .

          My question is, can the workaround be modified to work in this case?

          Greg Allen added a comment - We have been using the workaround above provided by inge4pres .  However, we just upgraded to 2.361.1 and CommandMap.getDefaultCommandMap() now returns a DelegatingCommandMap object ( https://javadoc.jenkins-ci.org/plugin/jakarta-mail-api/io/jenkins/plugins/jakarta/activation/DelegatingCommandMap.html) . My question is, can the workaround be modified to work in this case?

            Unassigned Unassigned
            lystor Mykola Ulianytskyi
            Votes:
            7 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated: