Compiled Java programs may be executed (under Condor) on any execution site with a Java Virtual Machine (JVM). To do this, Condor must be informed of some details of the JVM installation.
Begin by installing a Java distribution according to the vendor's instructions. We have successfully used the Sun Java Developer's Kit, but any distribution should suffice. Your machine may have been delivered with a JVM already installed - installed code is frequently found in /usr/bin/java.
Condor's configuration includes the location of the installed JVM. Edit the configuration file. Modify the JAVA entry to point to the JVM binary, typically /usr/bin/java. Restart the condor_ startd daemon on that host. For example,
% condor_restart -startd bluejay
The condor_ startd daemon takes a few moments to exercise the Java capabilites of the condor_ starter, query its properties, and then advertise the machine to the pool as Java-capable. If the set up succeeded, then condor_ status will tell you the host is now Java-capable by printing the Java vendor and the version number:
% condor_status -java bluejay
After a suitable amount of time, if this command does not give any output, then the condor_ starter is having difficulty executing the JVM. The exact cause of the problem depends on the details of the JVM, the local installation, and a variety of other factors. We can offer only limited advice on these matters, but here is an approach to solving the problem.
To reproduce the test that the condor_ starter is attempting, try running the Java condor_ starter directly. To find where the condor_ starter is installed, run this command:
% condor_config_val STARTER
This command prints out the path to the condor_ starter, perhaps something like this:
/usr/condor/sbin/condor_starter
Use this path to execute the condor_ starter directly with the -classad argument. This tells the starter to run its tests and display its properties.
/usr/condor/sbin/condor_starter -classad
This command will display a short list of cryptic properties, such as:
IsDaemonCore = True HasFileTransfer = True HasMPI = True CondorVersion = "$CondorVersion: 6.2$"
If the Java configuration is correct, there will also be a short list of Java properties, such as:
JavaVendor = "Sun Microsystems Inc." JavaVersion = "1.2.2" JavaMFlops = 9.279696 HasJava = True
If the Java installation is incorrect, then any error messages from the shell or Java will be printed on the error stream instead.
One identified difficulty occurs when the machine has a large quantity of physical RAM, and this quantity exceeds the Java limitations. This is a known problem for the Sun JVM. Condor appends the maximum amount of system RAM to the Java Maxheap Argument, and sometimes this value is larger than the JVM allows. The end result is that Condor believes that the JVM on the machine is faulty, resulting in nothing showing up as a result of executing the command condor_status -java.
The way to work around this particular problem is to modify the configuration file for those machines that may execute Java universe jobs. The JAVA_MAXHEAP_ARGUMENT macro is explicitly set to null in the configuration, to prevent Condor from appending the machine-specific, but too-big value. Then the Java Maxheap Argument is set (again, in the configuration) to the maximum value allowed for the JVM on that platform, using the JAVA_EXTRA_ARGUMENTS configuration variable. Note that the name of the switch that regulates the Java Maxheap Argument is different for different vendors' JVM.
The following is an example of the configuration fix for the Sun JVM:
# First set JAVA_MAXHEAP_ARGUMENT to null, to disable the default of max RAM JAVA_MAXHEAP_ARGUMENT = # Now set the argument with the Sun-specific maximum allowable value JAVA_EXTRA_ARGUMENTS = -Xmx1906m