Scatter Gather Demo

This demo uses Newton to build a traditional scatter-gather compute grid. The grid uses a number of distributed worker composites coordinating via a Java Space.

The aim of this demo is to build such a grid manually, explicitly installing the required composites in three separate Newton containers. In the Scatter Gather System Demo the same grid is set up using Newton Environments which automate much of what we do here and improve resilience.

This is not supposed to be a real world grid, in particular it doesn't make use of transactions or persistence to ensure delivery of all submitted tasks.

In this demo there are 3 composite types.

1. A Javaspace composite that acts as a coordination point for the grid
2. A Client that submits tasks to the grid
3. Several Worker composites that process the tasks and return the result
4. A Command Line Interface (CLI) that can be used to trigger the submission of work by the client.

The way the the demo works is that the client breaks the work it wants done down into tasks and writes entries wrapping these into the Javaspace. Meanwhile idle Workers are monitoring the space for new tasks. Whenever they spot one they take it, process it and return an entry wrapping the result to the space. Finally the client monitors the space for entries wrapping task results until it has taken one for every task it submitted, it then collates these and prints out the result.

Each of the composites listed above is deployed in its own factory bundle. The client and worker import a common API package from an API bundle. This API bundle and the client have an RMI-Codebase manifest header identifying the code needed to deserialize the objects sent over the network. To see the detail consult the component.bundle tasks of the ant build.xml file of the demo source code.

Prerequisites

Try the local Chainlink Demo first - this walks through some basic Newton concepts that are not covered here.

Booting the Newton container

In order to run the demo it is first necessary to start three Newton containers in the same fabric. Fabrics are used to give scope to distributed containers. Only containers belonging to the same fabric can see each others services. To start three containers run:

In terminal 1

$ ./container -fabricName=myfabric -instance=1

In terminal 2

$ ./container -fabricName=myfabric -instance=2

In terminal 3

$ ./container -fabricName=myfabric -instance=3

It is important that you remember to use your own fabric name, not "myfabric".

The -instance flag is used to separate the state of the different Newton containers. This makes it straightforward to run this demo on a single machine. You can also run the different Newton instances on different machines as long as your firewall is configured to forward the multicast packets Newton uses for discovery.

After starting Newton wait for the "Boot complete" message, after which Newton will make a command line available.

Booting the distributed runtime

Newton's distributed infrastructure makes use of multicast, so it is essential that your network and computers are not configured to block multicast traffic. If you are unsure of your setup, or having difficulty running this example the please see Troubleshooting Multicast.

Every instance of Newton starts up with the client side of the distributed infrastructure already installed. In this example we will manually boot the server side infrastructure. In one of the Newton containers run

> installer install etc/instances/reggie.composite
> installer install etc/instances/server-cds.composite

This installs the remote services registry, which Newton uses to detect and wire up services in different JVMs. It also starts the remote zone of CDS. All Newton containers share a common view of the content in CDS's remote zone.

Optionally you can start the Jini browser composite, a GUI tool for viewing the remote registry. You can use this to see the services that available to your group remotely.

> installer install etc/instances/jinibrowser.composite

The services may take a few seconds to come up - you'll get an error message at the next step if you are too quick.

Loading bundles into CDS

At this point the bundles used by the scatter-gather demo are not present in the CDS, so they must be loaded. Note that this doesn't install anything, it just makes resources available for future composite installations.

To load the demo bundles run the following in one of your Newton instances.

> cds scan remote examples/scattergather/build/lib

This loads all of the bundles in demo/build/lib into the remote zone of CDS, extracting metadata and indexing the bundles as they are loaded. Resources in the remote zone can be seen by all Newton containers in the same fabric.

As well as the demo bundles we are going to be using a Javaspace. There are currently two Javaspaces wrapped as Newton composite, Outrigger, the Jini TSK reference implementation, and Blitz, the leading open source implementation. These ship with the main Newton install, not with the demos, so their bundles must be loaded into CDS separately as follows:

> cds publish remote etc/cds/jini-service-bundles.xml

Here a CDS Publish File has been used to load the bundles into the remote Zone of CDS.

Running the demo

The rest of this demo is split over the three Newton containers that are now running.

In the container 1 install the Client and CLI composites as follows.

> installer install examples/scattergather/build/etc/cli.composite
> installer install examples/scattergather/build/etc/client.composite

In container 2 install the javaspace. Choose one of the following. Either Outrigger:

> installer install etc/instances/outrigger.composite

or Blitz:

> installer install etc/instances/blitz.composite

In the third container install a worker as follows:

> installer install examples/scattergather/build/etc/worker.composite

At this point we have set up a scatter-gather grid with one worker. The structure of the composites we've installed an their distribution among the containers is shown below.

As the composites are created Newton examines the their services and references and uses them to dynamically wire up the composites in the following arrangement.

To see the grid working we can use this CLI to submit some work to the grid.

> scattergather submit
[stdout] Submitted 100 tasks
> [stdout] completed 100 tasks in 18218ms
[stdout] status: success

The 100 tasks that are submitted don't really do any work, they just sleep for 0.1 seconds, so with one worker the time taken should be 10 seconds. From the output we can see that it actually took more than 18 seconds. Most of this is due to first time initalisation of the Javaspace, although there will always be some infrastructure overhead. Running it again gets us nearer to the expected time.

> scattergather submit
[stdout] Submitted 100 tasks
> [stdout] completed 100 tasks in 11721ms
[stdout] status: success

Of course a real grid has more than one worker, so we now install 2 more. We'll do this in container 3, although they could be anywhere.

> installer install examples/scattergather/build/etc/worker.composite
> installer install examples/scattergather/build/etc/worker.composite

Now we resubmit the 100 tasks to see the benefit of the extra workers.

> scattergather submit
[stdout] Submitted 100 tasks
> [stdout] completed 100 tasks in 4947ms
[stdout] status: success

This time the tasks are processed far faster, taking just under 5 seconds.

1. Try switching Javaspace, e.g. replacing Outrigger with Blitz without stopping the other composites. After the switch submit another job to check everything is still working.
2. Add and Remove more workers to the existing and additional Newon containers, and observe the results.
3. Uninstall everything using installer uninstall <descrtiptor> , and use bundles -i to confirm that the bundles used by the scatter-gather composites have been garbage collected.