How to Resolve  Class Loading Issues in ServiceNow MID Server

Is your ServiceNow MID Server running slow and encountering unexpected issues? 🤔 The culprit might be class loading problems. But don’t worry! In this article, we’ll show you how to identify and resolve these issues. Learn simple tips to improve the performance and reliability of your ServiceNow integrations. Ready to get started? Let’s dive in!

How Class Loading Issues Affect Your ServiceNow MID Server

Slow Performance

Frequent or improper class loading can slow down your application because the JVM spends extra time loading needed classes, causing delays.

Freezes and Timeouts

Long class loading times can cause the application to freeze temporarily. In a ServiceNow MID server, this might lead to timeouts and missed requests, affecting reliability.

Increased Wait Time

Class loading issues can make your application take longer to respond, impacting user experience and slowing down important tasks.

High Resource Usage

Handling class dependencies can use more CPU and memory. The JVM works harder to manage these tasks, putting extra load on the system.

Hard to Diagnose

Random class loading issues can be tough to identify and fix without detailed logs and analysis.

Scalability Issues

Poor class loading management can make it difficult for your application to handle more requests or larger amounts of data effectively.

Addressing Class Loading Issues in ServiceNow MID Server

The Java program below demonstrates how to address class loading issues by simulating scenarios where improper class loading might cause delays and inefficiencies:

import java.lang.reflect.InvocationTargetException;
import java.util.ArrayList;
import java.util.List;
import java.util.logging.Level;
import java.util.logging.Logger;

public class ClassLoadingIssueSimulator {
    private static final Logger LOGGER = Logger.getLogger(ClassLoadingIssueSimulator.class.getName());
    private static final List<ClassLoader> classLoaders = new ArrayList<>();
    private static final List<Object> loadedClasses = new ArrayList<>(); 

    public static void main(String[] args) {
        LOGGER.info("Starting Class Loading Issue Simulator...");

        int iterations = 10000; 

        for (int i = 0; i < iterations; i++) {
            LOGGER.info("Iteration " + (i + 1) + " of " + iterations);
            simulateClassLoadingIssues();
        }

        LOGGER.info("Class Loading Issue Simulator finished.");
    }

    private static void simulateClassLoadingIssues() {
        try {
            MyClassLoader myClassLoader = new MyClassLoader();
            classLoaders.add(myClassLoader); 

            Class<?> cls = myClassLoader.loadClass("LargeClass");
            Object instance = cls.getDeclaredConstructor().newInstance();
            loadedClasses.add(instance); 

            LOGGER.info("Loaded and instantiated class: " + cls.getName());

            cls.getMethod("performOperation").invoke(instance);

        } catch (ClassNotFoundException | InstantiationException | IllegalAccessException | NoSuchMethodException | InvocationTargetException e) {
            LOGGER.log(Level.SEVERE, "Class loading issue encountered: ", e);
        }
    }

    static class MyClassLoader extends ClassLoader {
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            if ("LargeClass".equals(name)) {
                return LargeClass.class;
            }
            throw new ClassNotFoundException("Class not found: " + name);
        }
    }

   
    public static class LargeClass {
        private int[] largeArray;

        public LargeClass() {
            this.largeArray = new int[1024 * 1024 * 25]; 
        }

        public void performOperation() {
            for (int i = 0; i < largeArray.length; i++) {
                largeArray[i] = i;
            }
            System.out.println("Performed operation in LargeClass.");
        }
    }
}

This Java program simulates memory pressure by repeatedly loading and instantiating a class using a custom class loader. A logger tracks the progress and any issues that arise during execution. The simulateClassLoadingIssues() method creates a new MyClassLoader, loads LargeClass, and invokes a method on it, which fills a large array to consume memory. Both the class loaders and instances of LargeClass are stored in lists to prevent garbage collection. The custom MyClassLoader only recognizes LargeClass and returns its class object. Over time, the program consumes increasing amounts of memory, leading to an OutOfMemoryError.

Simulation Class Loading Issues in ServiceNow MID server

Let’s run our application on the ServiceNow MID Server and see how Class Loading Issues look. First, create a JAR file from the program using the command:

jar cf ClassLoadingIssueSimulator.jar ClassLoadingIssueSimulator.class

Once a JAR file is created, let’s upload and run this program in the ServiceNow MID Server as documented in the MID Server setup guide. This guide provides a detailed walkthrough on how to run a custom Java application in the ServiceNow MID Server infrastructure. It walkthrough following steps:

1. Creating a ServiceNow application
2. Installing MID Server in AWS EC2 instance
3. Configuring MID Server
4. Installing Java application with in MID Server
5. Running Java application from MID server

We strongly encourage you to check out the guide if you are not sure on how to run custom Java applications in ServiceNow MID server infrastructure.

yCrash Identifies Class Loading Issues in ServiceNow MID Server

The yCrash report indicates a memory issue in the ClassLoadingIssueSimulator class. It was loaded by jdk.internal.loader.ClassLoaders$AppClassLoader and occupies approximately 99.34% of the total memory, consuming over 209 MB. The memory accumulation points to a likely memory leak or inefficiency in the class loading mechanism. This issue is causing significant memory usage, which may lead to performance degradation or OutOfMemoryError. Further details of the memory usage can be explored in the full report for a deeper analysis.

The yCrash report shows that the ClassLoadingIssueSimulator class, along with its associated objects, is consuming nearly all available memory (99.34%), indicating a potential memory leak. Specifically, an ArrayList named loadedClasses is retaining a significant amount of memory, with each element (LargeClass instances) consuming 100 MB. This insight can help in addressing class loading issues in systems like the ServiceNow MID Server, where inefficient class loading can lead to memory bloat and performance degradation. By identifying the largest objects and their memory consumption, the report guides developers in optimizing memory usage, potentially by releasing or reusing class loaders and instances more efficiently to avoid similar memory leaks in production systems. You can see the detailed report here.

Conclusion

yCrash helps identify and diagnose memory issues in applications by providing clear insights into which components are consuming the most memory. In this case, it highlighted that the ClassLoadingIssueSimulator and its objects were using nearly all available memory, helping us quickly locate the problem. By showing detailed information about the largest objects in memory, yCrash allows us to understand where inefficiencies or leaks might be happening. This information guides us in making improvements to optimize performance and prevent memory-related crashes. Overall, yCrash simplifies the process of identifying complex issues, making it easier to keep applications running smoothly. If you want to diagnose performance problems in your application using yCrash, you may register here.