When performing an operation on a background integration environment, it is frequently reported that the class cannot find an error and is part of the exception information.
Problem analysis was initially thought to be a problem with jar package dependencies. But looking at the business data, the same operation can sometimes go through the process normally. Initial exclusion of jar package dependencies. But what exactly is the problem? There is no more clue through the log. One
trick: When troubleshooting a problem, we want to find the root cause of the problem. This exception message is most likely caused by other problems, so we need to look ahead to the log. From what point of time will you read the log? Obviously, you need to find the first point in time when the exception occurred. According to this idea, we find the first point to run out of the anomaly, then go ahead and find a system exception:
The exception is obvious: too many files are open. Linux system can be used for the user, the process of some resource restrictions, specifically refer to the Ulimit command. With this exception information, presumably the process has opened too many files. View some of the system's configuration by Ulimit-a (or by using ulimit-n to see the maximum number of files that a process can open):
You can see that the maximum number of files that the throttling process can open is 1024. Find the process number of the service, using the Lsof-p pid | Wc-l, look at the number of open files, and find that the upper limit is indeed reached. This causes the problem to be found. Summary because the integration environment configuration is low, and testers set a high concurrency of the pressure test, resulting in the inability to open more files. Because the class also needs to open the jar file for reading when it loads, the class does not load properly into the persistence generation, resulting in problems that the class cannot find. When we look at the log, we often can't locate the problem directly through the log information, at this point we should suspect that the problem is caused by another problem.
Therefore, it is helpful to have a proper look ahead of the log for locating the problem.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Class could not find the problem tracking and analysis
