Exception in thread "main" java.lang.NoClassDefFoundError

[MPT]

Edit: We're using Open Studio 7.3.1

We have an issue where we run a job every 10 minutes and it occasionally fails with error

• Exception in thread "main" java.lang.NoClassDefFoundError: routines/system/RunStat 
  • at dataintegration.absencesandholidaystotable_1_2. AbsencesAndHolidaysToTable.<init (AbsencesAndHolidaysToTable.java:267)
  • at dataintegration.absencesandholidaystotable_1_2. AbsencesAndHolidaysToTable. main(AbsencesAndHolidaysToTable.java:8925)
• Caused by: java.lang.ClassNotFoundException: routines.system.RunStat
  • at java.net.URLClassLoader.findClass(Unknown Source)
  • at java.lang.ClassLoader.loadClass(Unknown Source)
  • at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
  • at java.lang.ClassLoader.loadClass(Unknown Source)
  • ... 2 more

This is difficult to investigate, because it is seemingly random: the job might work at 10:00, 10:10. 10:20 and at fail at 10:30 with the above error, then work again when executed at 10:40. It does not fail daily, but weekly. Usually only once before working again.

I would image a lock issue should not happen as these are shared libraries right? but we can't figure out what the cause is.

[Anonymous]

@Mikael Toivonen​, which version of studio are you using? I found one same issue had been reported on Bugtracker, it is better to create a new jira issue for R&D team to investigate it.

Regards

Shong

[DWyman1649849953]

The class is not available in Java Classpath.

You might be running your program using the jar command and class was not defined in the manifest file's ClassPath attribute.

[MPT]

We're using Open Studio 7.3.1. I edited that to the opening post too.

[MPT]

We have a Windows task scheduler executing this locally deployed job every 10 minutes. The job functions properly for days - until it doesn't. So the class is in the classpath when be build and deploy the job as a self-executable package.

But I will look into if some process of ours might modify the classpath without us realizing it and "sabotaging" the execution of this other job.

[MPT · Accepted solution]

I found the issue. When we build jobs, we always use the same target folder (D:\Deployment) for the compiled jobs, even when we built jobs from different projects. That means that all these jobs from different projects shared the D:\Deployment\lib folder. So what happened was that every now and then we re-built a job that altered the D:\Deployment\lib\routines.jar and that broke job #2 that was expecting to find someting from that jar that was not there. As a fix we will build jobs to project-specific sub-folders from now on so that the libraries go to different folders e.g. D:\Deployment\LEGAL\lib and D:\Deployment\HR\lib

[Anonymous]

@Mikael Toivonen​, thanks for sharing the solution, it is a good clue.