This directory contains code which demonstrates how JavaSpaces can be combined with a network launcher (class loader) to simplify configuration of remote nodes used in a distributed computation (10/2000, mnoble@cfa.harvard.edu). To use it you need a Tonic installation on some machine and have a JavaSpaces service up and running on it. This can be done by running the Tonic startServers script on some pretend MACHINE-1 which exists in FOOBAR.EDU: MACHINE-1> startServers Starting HTTP server to furnish JINI/JavaSpaces class files... ... process id is xxxx1 Starting rmid... ... process id is xxxx2 Starting Jini lookup server ... ... process id is xxxx3 Starting JavaSpaces ... ... process id is xxxx4 On a remote machine (i.e., connected to MACHINE-1 by some network, which is theoretically any machine on the internet) you might then invoke the tworker script as UNIX: REMOTE-MACHINE> sh tworker.sh MACHINE-1.FOOBAR.EDU 9999 WINDOWS: c:\ tworker.bat MACHINE-1.FOOBAR.EDU 9999 which will echo something like java -native -Djava.security.policy=policy.all -Dcom.sun.jini.lookup.groups=public -Dcom.sun.jini.lookup.locator=jini://MACHINE-1.FOOBAR.EDU/ -Doutrigger.spacename=JavaSpaces WebRun -E -j http://MACHINE-1.FOOBAR.EDU:9999/tonicw.jar Worker and attempt to download the tonic worker .jar file and execute Worker.class. If the download succeeds and the Worker is able to connect with the space you should see a message like found JavaSpaces = com.sun.jini.outrigger.SpaceProxy@0 At this point the Worker is running and waiting for tasks to perform, which it will retrieve from the space, execute, and return to the space upon completion. You can add tasks to the space by running one of the many Tonic application benchmarks, for example Pi: MACHINE-1> runJs ComputeMaster Pi -P 2 This writes 2 PI computation tasks to the space, which should be picked up immediately by REMOTE-MACHINE and executed: Computing Pi task # 0 ... some time goes by ... Computing Pi task # 1 That's it! Note that instead of using MACHINE-1 to run the master process we could've used any other host with Tonic and JavaSpaces installed. Finally, note that because the focus of Tonic is scientific computation, we intentionally ignore security concerns (and use permissive policy files). ---------------------- What's This All About? ---------------------- A classic problem with using distributed computation packages (e.g., PVM or MPI, to name just two) is that the administrative overhead of installation, configuration, and maintenance is considerable. And since these packages have traditionally used native-compiled binaries the problem worsens when one would like heterogeneous machines to simultaneously participate in computations. The combination of JavaSpaces + network launchers provides an elegant solution to these problems. What I've done is pull selected pieces of Jini/JavaSpaces client code into the Tonic worker jarfile (tonicw.jar, look at ../jsbench/Makefile for build details), so that remote nodes may participate in computations w/out needing to install the entire JavaSpaces distribution locally. This would require several megabytes, and ideally needs to be performed on each remote machine every time a new Jini/JavaSpaces version is released. Instead, by using a simple network launcher each remote node only needs to download a very small class (25k or so) to access tonicw.jar and be able to run the Worker.class code. This is a considerable simplification, and becomes more important as the number of remote nodes utilized for master/worker computations increases ----------------- Network Launchers ----------------- The network launcher used is a modified version of WebRun, written by Michael Sinz and currently located at http://www.sinz.org/Michael.Sinz/WebRun/ I chose this implementation because I didn't want to write my own just yet, and it contained everything I needed within a single file. Other (more complex/sophisticated) options include JNLP (from SUN) and JavaURL (developed by Tal Liron at http://www.amherst.edu/~tliron/javaurl). I've added one small modification Thread.currentThread().setContextClassLoader(loader); which ensures that the network loader created by WebRun has first crack at finding the Jini/Javaspaces classes, rather than an internal classloader created to access the codebase(s) referenced by your application. Apparently Sun refers to this issue as "The Legendary Codebase Problem of Assignment Compatability of Logically and Structurally Identical Classes Loaded From Different Classloaders"