Arbitrary ClassLoad failures in Java Protocol Driver

[Simone Heckmann]

Hi,

we have been using the Java Protocol Driver for a while now and we keep on running in situations like this:

A Java Protocol Thread has been properly configured and is running smoothly for a while.

Then suddenly after a restart of the engine, we get Errors from the class loader, like this:

Code:

[java:init:ERR /0:t_mdmprinter_out:09/17/2015 10:47:36] Call to class loader for hc/cloverleaf/mdmprinterV2J/ToDatabaseLink had an exception
java.lang.NoClassDefFoundError: hc/cloverleaf/mdmprinterV2J/ToDatabaseLink
Caused by: java.lang.ClassNotFoundException: hc.cloverleaf.mdmprinterV2J.ToDatabaseLink
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
[java:init:ERR /0:t_mdmprinter_out:09/17/2015 10:47:36] Class loader returned null for class hc/cloverleaf/mdmprinterV2J/ToDatabaseLink
[java:init:ERR /0:t_mdmprinter_out:09/17/2015 10:47:36] Call to pdjSetClass failed.
[pd  :pdtd:ERR /0:t_mdmprinter_out:09/17/2015 10:47:36] PD initialization FAILED!

But all the configured path are correct. The external jars and the .class file are still exactly where they are supposed to be. Even deleting and re-configuring the path isn’t helping the issue.

In most cases, we got so desperate that we deleted and recreated the whole process from scratch, wending up with the exact same configuration as before but suddenly it all works again.

We even checked and compared the .pni and .ini files but couldn’t find anything out of the ordinary.

Has anyone encountered similar issues ?

Regards,

Simone

Topic

[David Barr]

Maybe it has to do with how you are starting the host server. If you’re restarting the process from the NetMonitor then I think the process inherits the environment of the host server. You need to make sure that the environment of the host server is correct especially if you are starting the host server from init scripts rather than an interactive shell.

[Simone Heckmann]

Hi David,

so far, we’ve only seen this happening on Windows machines, where the host server is usually startet with the service.

In this context, what is the “right” environment and how do I check this?

If I understand you correctly, (re-)starting the hciss via command line might cause the java driver threads to behave differently?

Could you please elaborate?

Thanks.

By the way, we’ve just had the same error again with another customer!

This is a freakin epidemic!

[David Barr]

I think this is a problem with the CLASSPATH environmental variable not being set reliably. I’m mostly familiar with how this is set on Linux. I would think that you would set this in advanced system properties on Windows and that the host server probably runs as a Windows service, but I’m not as familiar with how to set up Cloverleaf on Windows. I suppose this could also be a file access issues to the .class files that are required. Make sure that whatever user is running your Cloverleaf service has access to the necessary files.

[Author]

Replies