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

Swarm and Git SCM fails with java.lang.NoClassDefFoundError: Could not initialize class java.util.Currency

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Won't Fix
    • Component/s: core
    • Environment:
      Jenkins 1.646, Git Plugin 2.4.1, Git client plugin 1.19.2; Ubuntu 14.04.1
      java 1.7.0 p95, OpenJDK 7u95-2.6.4-0 64-bit build 24.95-b01, mixed mode
    • Similar Issues:

      Description

      We are moving from a custom script to the Git SCM. Our previous script works fine, connecting to the remote agent and executing the script. The Git SCM errors out immediately, upon creating the git client it seems. For remote coordination we use Swarm.

      Attached is the complete build log, but the most relevant error seems to be:

      Caused by: java.lang.NoClassDefFoundError: Could not initialize class java.util.Currency
      

      I'm not sure how to further debug this, but happy to do whatever I can to get it up and running!

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          I don't think the "class not found" message is related to the git plugin, other than the fact that the git plugin is trying to make a remote call. I've assigned this to core in hopes someone on core can assist.

          Show
          markewaite Mark Waite added a comment - I don't think the "class not found" message is related to the git plugin, other than the fact that the git plugin is trying to make a remote call. I've assigned this to core in hopes someone on core can assist.
          Hide
          jshirley Jay Shirley added a comment -

          Thanks Mark!

          To be clear, if I disable the Git SCM and put in a build script to fetch from Git everything is fine. This behavior only starts if the project is configured to use the Git SCM. It also doesn't seem to occur if I use the same configuration in a local Vagrant image that doesn't use Swarm… but that's not testing the same behavior, so not too relevant.

          Show
          jshirley Jay Shirley added a comment - Thanks Mark! To be clear, if I disable the Git SCM and put in a build script to fetch from Git everything is fine. This behavior only starts if the project is configured to use the Git SCM. It also doesn't seem to occur if I use the same configuration in a local Vagrant image that doesn't use Swarm… but that's not testing the same behavior, so not too relevant.
          Hide
          markewaite Mark Waite added a comment -

          I suspect that without Git SCM, you probably aren't making many remote file system calls, or are making different types of remote file system calls. My first hunch is that the issue is somehow in your choice of virtual machine on the swarm client side, or possibly an unexpected incompatibility between your Jenkins version and the swarm client version you're using. I'm not a big user of swarm clients, but I have a few, and they run git just fine.

          Show
          markewaite Mark Waite added a comment - I suspect that without Git SCM, you probably aren't making many remote file system calls, or are making different types of remote file system calls. My first hunch is that the issue is somehow in your choice of virtual machine on the swarm client side, or possibly an unexpected incompatibility between your Jenkins version and the swarm client version you're using. I'm not a big user of swarm clients, but I have a few, and they run git just fine.
          Hide
          jshirley Jay Shirley added a comment -

          Aha, after running through incrementally adding all various options and found that this behavior kicks in when I restrict the job to a certain node type.

          We have two node types , I'll call them NodeA and NodeB. The specs are the exact same, they're AWS EC2 nodes (c4.8xlarge) on EBS.

          If I put in "Restrict where this job runs" on NodeA it works. If I put NodeB it fails. In our test environment, we only have one of each so I launched another node (NodeC) to see if it was something specific to our QA NodeB.

          Guess what? It's only NodeB, NodeC is totally fine. I'm sad.

          Should I leave this ticket open to further diagnose the problem with some guidance?

          Show
          jshirley Jay Shirley added a comment - Aha, after running through incrementally adding all various options and found that this behavior kicks in when I restrict the job to a certain node type. We have two node types , I'll call them NodeA and NodeB. The specs are the exact same, they're AWS EC2 nodes (c4.8xlarge) on EBS. If I put in "Restrict where this job runs" on NodeA it works. If I put NodeB it fails. In our test environment, we only have one of each so I launched another node (NodeC) to see if it was something specific to our QA NodeB. Guess what? It's only NodeB, NodeC is totally fine. I'm sad. Should I leave this ticket open to further diagnose the problem with some guidance?
          Hide
          markewaite Mark Waite added a comment -

          If you can find the relevant difference between NodeA, NodeB, and NodeC that causes NodeB to fail but its clone NodeC to not fail, there will likely be someone in the future who thanks you for learning that. Unfortunately, all my guesses are centered around differences in the java execution environment.

          Show
          markewaite Mark Waite added a comment - If you can find the relevant difference between NodeA, NodeB, and NodeC that causes NodeB to fail but its clone NodeC to not fail, there will likely be someone in the future who thanks you for learning that. Unfortunately, all my guesses are centered around differences in the java execution environment.
          Hide
          jshirley Jay Shirley added a comment -

          There is a minor kernel difference, aside from that they're provisioned nearly identical (we pin most packages, and it's all automated).

          I'll leave this ticket open until Monday to see if someone else is interested, and then terminate the problematic instance and close the ticket.

          Thank you for your help Mark!

          Show
          jshirley Jay Shirley added a comment - There is a minor kernel difference, aside from that they're provisioned nearly identical (we pin most packages, and it's all automated). I'll leave this ticket open until Monday to see if someone else is interested, and then terminate the problematic instance and close the ticket. Thank you for your help Mark!
          Hide
          jshirley Jay Shirley added a comment -

          I'm going to go ahead and close this issue, I've terminated our EC2 instance since those things aren't cheap!

          If this happens again, will reopen and try to figure out the differences.

          Show
          jshirley Jay Shirley added a comment - I'm going to go ahead and close this issue, I've terminated our EC2 instance since those things aren't cheap! If this happens again, will reopen and try to figure out the differences.

            People

            • Assignee:
              Unassigned
              Reporter:
              jshirley Jay Shirley
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: