Java.lang.NoClassDefFoundError


Description

This error code typically occurs when a runtime cluster or cloud JVM cannot access a jar file on its fileshare at runtime. The java class loader loads these jar files dynamically and if at any point it cannot access this given file you will see this error thrown continuously.

NoClassDefFoundError is a common error in Java which occurs if a Java Class Loader is not able to find a particular class/file from a Java Class Path at runtime. Typically, we see this error in Window’s based environments.

If you encounter the error or are using the cluster runtime on a Windows environment, we would encourage you to take advantage of the property setting on the Basic Properties Tab called 'Use Local Storage for Runtime Assets'. By enabling this property along with providing a local directory under 'Working Data Local Storage Directory' all applicable assets will be copied from the fileshare to the local storage device (e.g.  working directory and temp files; JARs for runtime, connector, and custom libraries; and  Java runtime libraries (JRE/JDK).  See a sample screen shot below of the properties.



There are several causes we typically see for this instability, namely the following:
 

Snapshot and/or backups on the node JVMs

Snapshots/backups interfere with the JVM and its ability to communicate with the fileshare. The following is recommended:

  1. Never snapshot, we do not recommend taking snapshots of node JVMs or any directories local to the node as all of the data on the node is temporary
  2. Once at setup/installation do an initial node preparation (install any necessary utilities/java/etc) and take a snapshot at this point in time. That snapshot should be sufficient moving forward
  3. If it is insisted to consistently snapshot (ongoing snapshots), we recommend to implement a maintenance process where the following is performed:
    1. Bring down the node JVM
    2. Take a snapshot at this point in time
    3. Restart the Boomi application
    4. Repeat in a rolling fashion until all nodes are snapshotted as needed

 

Anti-virus running on the JVM nodes and/or fileshare

We have both a community article and help guide reference to show the performance, instability and quarantining problems caused by Anti Virus. If Anti Virus is needed on your server, please exclude the directories mentioned in the community article from the scan.
 

Server patching/maintenance 

For any Windows environment, Operating System patching is expected. If the fileshare is rebooted, all nodes need to be rebooted as well after it. The nodes read and write to/from the fileshare in a persistent stream, and if that stream is broken the connection as a whole may be broken. One symptom of this is a break in runtime logging for that given node after that point in time. 
 

Distributed File System (DFS)

We have seen Distributed File Systems/DFS replication cause stability problems in Window's based environments. Rather then using a DFS, try using a simple UNC path to the fileshare to determine if the DFS architecture is causing instability. 

Note: There are other environmental factors that may not be known at this point in time that can cause problems as well.