We have a strange issue with two Java processes A and B that load same jar file (not 2 separate copies of the same file, same actual file).
The .jar file was replaced with a newer copy (renamed to .jar_BACK, then a new file copied in its pace), and one of the Java processes (A) restarted. The other Java process (B) keeps running.
Process A works without any problem.
Process B gets a NoClassDefFoundError exception when it tries to use one of the classes in the .jar we updated. The class that is "not found" was already loaded before.
Investigation by jar -x
shows that the "missing" class is actually present in both old and new version of the jar, in same location within the jar file and the class itself is unchanged.
Restarting process B fixes the problem.
What would be causing such a behavior?
My current guess is: either standard Java classloader or some custom classloader invalidates classes from a jar when .jar file is renamed. But I can't find any documentation on this, and my previous understanding was that classloader does not do any such monitoring for missing .jar files.
I am pretty sure we're not using any custom class loaders, either.
Java version: 1.8.0_144-b01
OS version: Red Hat Enterprise Linux Server release 6.9 (Santiago)