Chapter 28.  Introduction to some of the functionalities of ProActive

This chapter will present some of the facilities offered by ProActive, namely :

28.1. Parallel processing and collaborative application with ProActive

Distribution is often used for CPU-intensive applications, where parallelism is a key for performance.

A typical application is C3D. 

Note that parallelisation of programs can be facilitated with ProActive, thanks to asynchronism method calls, as well as group communications.

28.2. C3D : a parallel, distributed and collaborative 3D renderer

C3D is a Java benchmark application that measures the performance of a 3D raytracer renderer distributed over several Java virtual machines using Java RMI. It showcases some of the benefits of ProActive, notably the ease of distributed programming, and the speedup through parallel calculation.

Several users can collaboratively view and manipulate a 3D scene. The image of the scene is calculated by a dynamic set of rendering engines using a raytracing algorithm, everything being controlled by a central dispatcher.

the active objects in the c3d application

28.2.1. 1. start C3D

using the script c3d_no_user

A "Dispatcher" object is launched (ie a centralized server) as well as 4 "Renderer" objects, that are active objects to be used for parallel rendering.

the 4 renderers are launched

the dispatcher GUI is launched

The bottom part of the window allows the addition and removal of renderers.

 

28.2.2. 2. start a user

using c3d_add_user

- connect on the current host (proposed by default) by just giving your name

for example the user "alice"

- spin the scene, add a random sphere, and observe how the action takes place immediately

- add and remove renderers, and observe the effect on the "speed up" indication from the user window.

Which configuration is the fastest for the rendering?

Are you on a multi-processor machine?

* you might not perceive the difference of the performance. The difference is better seen with more distributed nodes and objects (for example on a cluster with 30+ renderers).

 

28.2.3. 3. start a user from another machine

using the c3d_add_user script, and specifying the host (NOT set by default)

If you use rlogin, make sure the DISPLAY is properly set.

You must use the same version of ProActive on both machines!

- test the collaborative behavior of the application when several users are connected.

Notice that a collaborative consensus must be reached before starting some actions (or that a timeout occured).

 

28.2.4. 4. start IC2D to visualize the topology

- to visualize all Active objects, you need to acquire ("monitoring" menu) :

- the machine on which you started the "Dispatcher"

- the machine on which you started the second user

- add random spheres for instance, and observe messages (Requests) between Active Objects.

- add and remove renderers, and check graphically whether the corresponding Active Objects are contacted or not, in order to achieve the rendering.

- you can textually visualize this information by activating "add event timeline for this WorldObject" on the World panel with the right mouse button, and then "show the event list window" on the top menu window

 

28.2.5. 5. drag-and-drop migration

- from IC2D, you can drag-and-drop active objects from one JVM to another. Click the right button on a C3DRenderingEngine, and drag and drop it in another JVM. Observe the migration taking place.

- add a new sphere, using all rendering engines, and check that the messages are still sent to the active object that was asked to migrate.

- as migration and communications are implemented in a fully compatible manner, you can even migrate with IC2D an active object while it is communicating (for instance when a rendering action is in progress). Give it a try!

Since version 1.0.1 of the C3D example, you can also migrate the client windows!

 

28.2.6. 6. start a new JVM in a computation

manually you can start a new JVM - a "Node" in the ProActive terminology - that will be used in a running system.

- on a different machine, or by remote login on another host, start another Node, named for instance NodeZ :

under linux :startNode.sh rmi://mymachine/NodeZ & (or startNode.bat rmi://mymachine/NodeZ)

The node should appear in IC2D when you request the monitoring of the new machine involved (Monitoring menu, then "monitor new RMI host".

- the node just started has no active object running in it. Drag and drop one of the renderers, and check that the node is now taking place in the computation :

- spin the scene to trigger a new rendering

- see the topology

* if you feel uncomfortable with the automatic layout, switch to manual using the "manual layout" option (right click on the World panel). You can then reorganize the layout of the machines.

- to fully distribute the computation, start several nodes (you need 2 more) and drag-and drop renderers in them.

Depending on the machines you have, the complexity of the image, look for the most efficient configuration.

 

28.2.7. 7. have a look at the source code for the main classes of this application :

org.objectweb.proactive.examples.c3d.C3DUser.java

org.objectweb.proactive.examples.c3d.C3DRenderingEngine.java

org.objectweb.proactive.examples.c3d.C3DDispatcher.java

look at the method public void processRotate(org.objectweb.proactive.Body body, String methodName, Request r) that handles election of the next action to undertake.

 

28.3. Synchronization with ProActive

ProActive provides an advanced synchronization mechanism that allows an easy and safe implementation of potentially complex synchronization policies.

This is illustrated by two examples :

  • The readers and the writers

  • The dining philosophers

28.3.1. The readers-writers

The readers and the writers want to access the same data. In order to allow concurrency while ensuring the consistency of the readings, accesses to the data have to be synchronized upon a specified policy. Thanks to ProActive, the accesses are guaranteed to be allowed sequentially.

The implementation with ProActive uses 3 active objects : Reader, Writer, and the controller class (ReaderWriter).

 

28.3.1.1. 1. start the application

using the readers script

ProActive starts a node (i.e. a JVM) on the current machine, and creates 3 Writer, 3 Reader, a ReaderWriter (the controller of the application) and a ReaderDisplay, that are active objects.

a GUI is started that illustrates the activities of the Reader and Writer objects.

28.3.1.2. 2. look and check the effect of different policies : even, writer priority, reader priority

What happens when priority is set to "reader priority" ?

 

28.3.1.3. 3. look at the code for programming such policies

in org.objectweb.proactive.examples.readers.ReaderWriter.java

More specifically, look at the routines in :

public void evenPolicy(org.objectweb.proactive.Service service)

public void readerPolicy(org.objectweb.proactive.Service service)

public void writerPolicy(org.objectweb.proactive.Service service)

Look at the inner class MyRequestFilterm that implements org.objectweb.proactive.core.body.request.RequestFilter

How does it work?

 

28.3.1.4. 4. Introduce a bug in the Writer Priority policy

For instance, let several writers go through at the same time.

- observe the Writer Policy policy before recompiling

- recompile (using compile.sh readers or compile.bat readers)

- observe that stub classes are regenerated and recompiled

- observe the difference due to the new synchronization policy : what happens now?

- correct the bug and recompile again ; check that everything is back to normal 

28.3.2. The dining philosophers

The "dining philosophers" problem is a classical exercise in the teaching of concurrent programming. The goal is to avoid deadlocks.

We have provided an illustration of the solution using ProActive, where all the philosophers are active objects, as well as the table (controller) and the dinner frame (user interface).

 

28.3.2.1. 1. start the philosophers application

with philosophers.sh or philosophers.bat

ProActive creates a new node and instantiates the active objects of the application : DinnerLayout, Table, and Philosopher

the GUI is started.

28.3.2.2. 2. understand the color codes

Philosophers

philosophing

hungry, wants the fork !

eating

Forks

taken

free

28.3.2.3. 3. test the autopilot mode

The application runs by itself without encountering a deadlock.

 

28.3.2.4. 4. test the manual mode

Click on the philosophers' heads to switch their modes

Test that there are no deadlocks!

Test that you can starve one of the philosophers (i.e. the others alternate eating and thinking while one never eats!)

 

28.3.2.5. 5. start the IC2D application

IC2D is a graphical environment for monitoring and steering of distributed and metacomputing applications.

- being in the autopilot mode, start the IC2D visualization application (using ic2d.sh or ic2d.bat)

 

the ic2d GUI is started. It is composed of 2 panels : the main panel and the events list panel

- acquire you current machine

menu monitoring - monitor new RMI host

It is possible to visualize the status of each active object (processing, waiting etc...), the communications between active objects, and the topology of the system (here all active objects are in the same node) :

28.4. Migration of active objects

ProActive allows the transparent migration of objects between virtual machines.

A nice visual example is the penguin's one.

This example shows a set of mobile agents moving around while still communicating with their base and with each other. It also features the capability to move a swing window between screens while moving an agent from one JVM to the other.

28.4.1. 1. start the penguin application

using the penguin script.

28.4.2. 2. start IC2D to see what is going on

using the ic2d script

acquire the machines you have started nodes on

28.4.3. 3. add an agent

- on the Advanced Penguin Controller window : button "add agent"

an agent is materialized by a picture in a java window.

- select it, and press button "start"

- observe that the active object is moving between the machines, and that the penguin window disappears and reappears on the screen associated with the new JVM.

28.4.4. 4. add several agents

after selecting them, use the buttons to :

- communicate with them ("chained calls")

- start, stop, resume them

- trigger a communication between them ("call another agent")

28.4.5. 5. move the control window to another user

- start a node on a different computer, using another screen and keyboard

- monitor the corresponding JVM with IC2D

- drag-and-drop the active object "AdvancedPenguinController" with IC2D into the newly created JVM : the control window will appear on the other computer and its user can now control the penguins application.

- still with IC2D, doing a drag-and-drop back to the original JVM, you will be able to get back the window, and control yourself the application.