JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-482  -  Kryo serialization uses wrong class loader upon deserialization
Posted Dec 29, 2016 - updated Dec 30, 2016
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Samples
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Always
  • Severity
    Normal
  • Targetted for
    icon_milestones.png JPPF 5.2.4
Issue description
From this forums post. We found evidence that Kryo instances cache a mapping of class name to class object, causing class objects from the same class loader to always be used and preventing classes with the same name but from a new class laoder from being used.
Steps to reproduce this issue
In a simple 1 server + 1 node grid configured for Kryo serialization, submit tasks like this:
public class MyTask extends AbstractTask<String> {
  private static int myfield = 1;
 
  @Override
  public void run() {
    setResult(String.format("myfield = %d", myfield));
  }
}
then run a client application to submit a job with one instance of the task, like this:
public class TestKryo {
  public static void main(final String[] args) {
    JPPFConfiguration.set(JPPFProperties.OBJECT_SERIALIZATION_CLASS, "org.jppf.serialization.kryo.KryoSerialization");
    try (JPPFClient client = new JPPFClient()) {
      JPPFJob job = new JPPFJob();
      job.add(new MyTask());
      Task<?> task = client.submitJob(job).get(0);
      if (task.getThrowable() != null) System.out.println("got exception: " + ExceptionUtils.getStackTrace(task.getThrowable()));
      else System.out.println("result: " + task.getResult());
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}
==> this will output "result: myfield = 1"

Then change the value of "myfield" to 2 in the task code, and run the client application a 2nd time: the output still shows "myfield = 1", indicating that the new version of the class was not used.

#5
Comment posted by
 lolo4j
Dec 30, 08:46
Fixed in: