JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF

The open source
grid computing
solution

 Home   About   Features   Download   Documentation   On Github   Forums 

Specifying alternate serialization schemes

From JPPF 4.2 Documentation

Jump to: navigation, search

Contents

Main Page > Customizing JPPF > Alternate serialization schemes

Throughout its implementation, JPPF performs objects transport and associated serialization by the means of a single interface: JPPFSerialization. By configuring a specific implementation of this interface, you can change the way object serialization and deserialization are performed in a JPPF grid.


Note 1: when an alternate serialization scheme is specified, it must be used by all JPPF clients, servers and nodes, otherwise JPPF will not work. The implementation class must also be present in the classpath of all JPPF components.

Note 2: to the difference of JPPF 3.x and earlier versions, serialization schemes now also apply to objects passed via the management APIs. This implies that the nodes must always have the JMXMP protocol library (jmxremote_optional-1.0_01-ea.jar) in their classpath.

1 Implementation

To create a new serialization scheme, you simply need to implement JPPFSerialization, defined as follows:

public interface JPPFSerialization {

  // Serialize an object into the specified output stream
  void serialize(Object o, OutputStream os) throws Exception;

  // Deserialize an object from the specified input stream
  Object deserialize(InputStream is) throws Exception;
}

For example, we could wrap the default Java serialization into a serialization scheme as follows:

public class DefaultJavaSerialization implements JPPFSerialization {
  @Override
  public void serialize(final Object o, final OutputStream os) throws Exception {
    new ObjectOutputStream(os).writeObject(o);
  }

  @Override
  public Object deserialize(final InputStream is) throws Exception {
    return new ObjectInputStream(is).readObject();
  }
}

2 Specifying the JPPFSerialization implementation class

This is done in the JPPF configuration file, by adding this property:

# Define the implementation of the JPPF serialization scheme
jppf.object.serialization.class = my_package.MyJPPFSerialization

Where my_package.MyJPPFSerialization implements the interface JPPFSerialization.

3 Built-in implementations

Out of the box, JPPF provides 3 serialization schemes:

3.1 Default serialization

This is the default Java serialization mechanism, using the known JDK classes java.io.ObjectInputStream and java.io.ObjectOutputStream. It is used by default, when no serialization scheme is specified. The corresponding implementation class is DefaultJavaSerialization.

3.2 Generic JPPF serialization

This is a serialization scheme implemented from scratch, which functions pretty much like the standard Java mechanism with one major difference: it enables the serialization of classes that do not implement java.io.Serializable nor java.io.Externalizable. This allows developers to use classes in their tasks that are not normally serializable and for which they cannot access the source code. We understand that it breaks the contract specified in the JDK for serialization, however it provides an effective workaround for dealing with non-serializable classes in JPPF jobs and tasks.

The JPPF implementation relies on an extension of the standard mechanism by defining 2 new classes: JPPFObjectInputStream and JPPFObjectOutputStream.

Apart from this, it conforms to the specifications for the standard ObjectInputStream and ObjectOutputStream classes, in that it processes transient fields in the same manner, and handles the special cases when a class implements the methods writeObject(ObjectOutputStream) and readObject(ObjectInputStream), and the java.io.Externalizable interface.

This implementation is also slower than the default Java one: serialization and deserialization of an object graph takes generally around 50% more time. This overhead will be significant essentially for very short-lived tasks (i.e. a few milliseconds). It is thus recommended to use the default Java serialization whenever it is possible.

To specify this scheme in your JPPF configuration:

jppf.object.serialization.class = org.jppf.serialization.DefaultJPPFSerialization

3.3 XStream-based serialization

JPPF has a built-in Object Stream Builder that uses XStream to provide XML serialization: XstreamSerialization. To use it, simply specify:

jppf.object.stream.builder = org.jppf.serialization.XstreamSerialization

in the JPPF configuration files.


You will also need the XStream 1.3 (or later) jar file and the xpp3 jar file available in the XStream distribution

3.4 Kryo serialization sample

The Kryo serialization sample provides an implementation of JPPFSerialization which uses the Kryo library for serializing and deserializing Java objects.

Main Page > Customizing JPPF > Alternate serialization schemes

JPPF Copyright © 2005-2020 JPPF.org Powered by MediaWiki