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

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Critical Critical
    • core
    • 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

      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!

          [JENKINS-32735] Swarm and Git SCM fails with java.lang.NoClassDefFoundError: Could not initialize class java.util.Currency

          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.

          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.

          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.

          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.

          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.

          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.

          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?

          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?

          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.

          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.

          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!

          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!

          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.

          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.

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

              Created:
              Updated:
              Resolved: