Javaspaces: the Codebase Problem and a Solution
Download the source code for the solution described below, here.
Anyone who has used Javaspaces has probably achieved a measure of success on one or two machines, then started to think more about how to deploy their solution. They might ask…
“How do the other computers get the libraries needed to execute work without my altering their classpath?”
This is where the “codebase” comes in. Javaspaces/JINI (and other Java/RMI technologies for that matter,) have the ability to query a url for a particular class or jar file, and receive bytes from that request. That downloaded bytecode can then be added to the ClassLoader of the running JVM. For further explanation, see this excellent article.
In short, an Http server can easily serve classes OR jar files. However, configuring the client computers to take advantage of the available code still exists as a task. The scenario can increase in complexity based on added jars and new tasks to execute. One day, three jars served up may be enough. A month from then, perhaps fifteen jars are needed.
If you didn’t read the article mentioned above – Note the following… If the codebase url ends in a slash – “/” then the url points to the root of a classpath. However, if the url is a list of jars, separated by spaces, then that specific jar is served by the Http server instead. It is possible to do both:
-Djava.rmi.server.codebase=”http://poobah:8080/MyClasses.jar http://poobah:8080/ http://poobah:8080/log4j1-X.jar”
So if we serve multiple jars to the network, then obviously this configuration path can become long. When mutliple machines start participating, maintaining the proper list can be a problem. Also, one hard coded Http server address is hardly fault tolerant. Some failover ability is needed and lord yes, some simplicity.
I ran into this problem myself while working with a couple Grid Computing frameworks and decided to make my life more simple. The code for my solution can be downloaded here, free to anyone who’d like to use it. (See the link at the bottom of this post.) The code is simple in concept and involves three components:
1. A small Http Server to handle requests.
2. A multicast listener (my own grid client processes extend a multicast base class that finds the url automatically on a LAN)
3. A jar indexer. The indexer should be pointed to a directory, and will recursively index every jar found in its path (including subdirectories.) One url is then needed to serve any class file found in any of the jars.
What this gives me, is the ability to always treat my jar serving http address as if it’s pointing to the root of an unzipped classpath, even though I may be actually serving classes from fifty jar files. Further, my grid clients can automatically find new jar servers if one of the jar servers goes down, since the servers themselves listen for requests and answer with their own url. This means that none of my grid computing remote computers require any rmi codebase configuration parameter at all. All I have to do to serve a new jar is drop the jar file into the path my jar server is indexing and it will be picked up and its classes will be available.
I am currently working on a more robust solution with a visual administration interface coupled with the ability to manage participating grid client tasks.
(repeat…) Download the source code for the solution described below, here.
No comments yet
