Package org.objectweb.proactive.core.classloader

This package holds most of the mechanism for dynamic classloading through ProActiveRuntimes.

See:
Description

Class Summary

ProActiveClassLoader	This class defines a class loader that can fetch classes from other referenced ProActive runtimes.
ProActiveClassLoaderHelper	Instances of this class are created and used from the ProActiveClassLoader by reflection, in order to work in a dedicated namespace.
ProActiveRMIClassLoaderSpi	This class allows dynamic remote downloading of classes from other proactive runtimes when using RMI as the communication protocol, or when streams are marshalled using the RMI mechanism.

Package org.objectweb.proactive.core.classloader Description

This package holds most of the mechanism for dynamic classloading through ProActiveRuntimes. Other classes involved are ProActiveRuntimeImpl and ClassDataCache.

This mechanism is not the default class downloading mechanism. It can be used for hierarchical deployment using deployment descriptors. It provides an alternative solution to RMI dynamic class downloading when the codebase is not available or incorrectly set, or when http is not available for class downloading (for instance with some firewalls setups, or with subnetworks with private IPs).

Example : hierarchical deployment

Consider three runtimes 1, 2 and 3. We want to perform a hierarchical deployment of objects of class B. Hierarchical deployment means we initially have runtime 1, and from runtime 1 we create runtime 2 (and an active object of type A on runtime 2), the from runtime 2 we create runtime 3 (and an active object of type B on runtime 3). This kind of deployment is useful when deploying into a subnetwork with private IPs. The bytecode for classes A and B is only available on runtime 1. We will show a hierarchical deployment using the standard RMI mechanism (figure 1), then using ProActive classloading mechanism (figure 2).

RMI dynamic class downloading

If from runtime 1 someone tries to create an active object of type A, with the standard RMI dynamic classloading mechanism, the bytecode for A is downloaded from the web server on runtime 1 because the ProActive Meta-Object Protocol received the creation request as an RMI invocation and was able to read the annotated codebase. ProActive runs a web server for distributing classes on each runtime, and annotations are automatic for remote invocations. However, we have a problem if from runtime 2 we try to create an active object of type B on runtime 3. Indeed, RMI tries to fetch class data of B from runtime 2, but the data for B is not available on runtime 2. The codebase points to runtime 2, not to runtime 1 where B is. B cannot be instantiated on runtime 3.

Dynamic class downloading through runtimes.

We assume that runtime 2 is linked (through a "hook") to runtime 1 and that runtime 3 is linked to runtime 2. This linkage is automatic when the option "proactive.classloader" is enabled and when runtime 2 is created from runtime 1 and runtime 3 is created from runtime 2. In this case, whenever a class is missing in runtime 3, the runtime classloader (the RMI classloader is not used) looks for the class in the parent runtime, the runtime 2. This is done using the current inter-runtimes communication protocol, for instance RMI. Runtime 2 checks whether its local cache contains the class B, and if it doesn't, it looks for the class B in runtime 1 (and so on). It retreives the class data, stores it in the cache, and sends the data to runtime 3. B can be instantiated on runtime 3.

Set-up

The ProActive class downloading mechanism is set up as follows :
- The property "proactive.classloader" should be set to "enable" in the runtime that initiates the deployment - When a new runtime is created from a deployment descriptor, it holds a reference on the runtime that created it.
- This new runtime is created using ProActiveClassLoader as the system classloader.
- If RMI is the communication protocol, a ProActiveRMIClassLoaderSpi is also created.

How does it work?

The ProActive class downloading mechanism works as follows :
- new runtimes/jvms are created with the parameter "java.system.class.loader=org.objectweb.proactive.core.classloader.ProActiveClassLoader"
- The java.system.class.loader property sets ProActiveClassLoader as the system classloader, thus ProActiveClassLoader loads all non-system classes. It first tries to load a class from the classpath, and if this fails, it asks its father runtime to send the class bytecode and defines it locally. This process is recursive : the father runtime, if it cannot find the class bytecode, will ask its parent runtime if it has one. Otherwise it returns null.
- When incoming streams - corresponding to remote invocations - are deserialized, the same mechanism takes place. If RMI is the communication protocol, the ProActiveRMIClassLoaderSpi ensures that ProActiveClassLoader will be used to load the classes. (only works for 1.4+ jvms)

Currently, although incoming streams contain annotated classes, and therefore a reference to a http class server, the standard RMI dynamic classloading mechanism is not used at all, and dynamic downloading only occurs through inter-runtimes communications.

Current limitations

- Classes are only looked for in the parent runtimes, and there is only one parent runtime for a given runtime. We may later add the possibility to look for classes in runtime acquaintances.
- There are no performance / stress benchmarks so far.

Author:

Matthieu Morel