The following information applies to Java WS Core and those services built on it.

Logging in the Java WS Core is based on the Jakarta Commons Logging API. Commons Logging provides a consistent interface for instrumenting source code while at the same time allowing the user to plug-in a different logging implementation. Currently we use Log4j as a logging implementation. Log4j uses a separate configuration file to configure itself. Please see Log4j documentation for details on the configuration file format.

   #for debug level logging from org.globus.package.FooClass 
   log4j.category.org.globus.package.name.FooClass=DEBUG
   #for warnings from org.some.warn.package
   log4j.category.org.some.warn.package=WARN
   

To turn on debug logging for the Managed Executable Job Service (MEJS), add the following entry to the container-log4j.properties file:

log4j.category.org.globus.exec.service.exec=DEBUG

To turn on debug logging for the delegated proxy management code, add the following entry to the container-log4j.properties file:

log4j.category.org.globus.exec.service.utils=DEBUG

To turn on debug logging for the Managed Multi Job Service (MMJS), add the following entry to the container-log4j.properties file:

log4j.category.org.globus.exec.service.multi=DEBUG

To turn on debug logging for the Managed Job Factory Service (MJFS), add the following entry to the container-log4j.properties file:

log4j.category.org.globus.exec.service.factory=DEBUG

To turn on debug logging for all GRAM code, add the following entry to the container-log4j.properties file:

log4j.category.org.globus.exec=DEBUG

Follow the pattern to turn on logging for other specific packages or classes.

Both the service and Java client API code contain special debugging statements which output certain timing data to help in determining performance bottlenecks.

The service code uses the PerformanceLog class to output the timings information. To turn on service timings logging without triggering full debug logging for the service code, add the following lines to the container-log4j.properties file:

log4j.category.org.globus.exec.service.factory.ManagedJobFactoryService.performance=DEBUG
log4j.category.org.globus.exec.service.exec.ManagedExecutableJobResource.performance=DEBUG
log4j.category.org.globus.exec.service.exec.StateMachine.performance=DEBUG

The Java client API has not been converted over to using the PerformanceLog class, so the debug statements are sent at the INFO level to avoid having to turn on full debug logging. To turn on client timings logging without triggering full debug logging for the client code, add the following line to the container-log4j.properties file:

log4j.category.org.globus.exec.client.e=INFO

There are two parsing scripts available in the source distribution that aren't distributed in any GPT package for summarizing the service and client timings data. The are located in ws-gram/service/java/test/throughput/, and are named parse-service-timings.pl and parse-client-timings.pl. They both simply take the path of the appropriate log file that contains the timing data. These scripts work fine with log files that have other logging statements mixed with the timing data.

It may be necessary to debug the scheduler scripts if jobs aren't being submitted correctly, and either no fault or a less-than-helpful fault is generated. Ideally we would like that this not be necessary; so if you find that you must resort to this, please file a bug report or let us know on the discuss e-mail list.

By turning on debug logging for the MEJS (see above), you should be able to search for "Perl Job Description" in the logging output to find the perl form of the job description that is sent to the scheduler scripts.

Also by turning on debug logging for the MEJS, you should be able to search for "Executing command" in the logging output to find the specific commands that are executed when the scheduler scripts are invoked from the service code. If you saved the perl job description from the previous paragraph, then you can use this to manually run these commands.

There is a perl job description attribute named logfile that isn't currently supported in the XML job description that can be used to print debugging info about the execution of the perl scripts. The value for this attribute is a path to a file that will be created. You can add this to the perl job description file that you created from the service debug logging before manually running the script commands.

Beyond the above advice, you may want to edit the perl scripts themselves to print more detailed information. For more information on the location and composition of the scheduler scripts, please consult the GRAM4 Scheduler Interface Tutorial.