GT 4.2.1 Migrating Guide for GRAM4

In GRAM4 an administrator can configure a default local resource manager being used for job submission if the client did not specify any in a job submission request. Check section Defining a default local resource manager in the System Administrator's Guide for more information.

The log4j configuration for audit logging in GRAM4 in 4.2 is slightly different compared to the 4.0 series. This involves log4j and database configuration changes. For the log4j configuration check section section Configure Log4j in the System Administrator's Guide for more information. For the database related changes check Configure the Database in JNDI in the System Administrator's Guide.

An administrator can configure lifetime parameters for all jobs in GRAM4's JNDI configuration. In short these parameters restrict the maximum lifetime a client can set on a job, and the maximum time a job is kept in the container and thus in the persistence directory after the job had been fully processed. Check section Job Lifetime in the Execution key concepts and section Job lifetime configuration in the System Administrator's Guide for more information.

By default GRAM4 in the 4.0 series does Web Service invocations when calling RFT to perform staging and file cleanup. The default in GRAM4 in 4.2 is local java calls to significantly improve performance in jobs with staging and file cleanup. If GRAM4 is configured to use RFT in a separate machine local invocations are disabled. For more information check the section GRAM4 - RFT interaction in the System Administrator's Guide

An administrator can configure the number of threads in the thread-pool that is responsible for handling scheduler events. The default size should be fine for all Scheduler Event Generators (SEGs) provided by Globus. It might be interesting for custom written SEGs. Check section Configuring thread-pools in the System Administrator's Guide for more information.

Due to the WSRF, WSN and WS-Adressing specification upgrade some namespaces changed. All occurences of the following old 4.0 namespaces must be updated to the new 4.2 namespaces.

Additionally, in a job description the ReferenceProperties element must be renamed to ReferenceParameters.

The following shows a factoryEndpoint element of a 4.0 job description and a 4.2 job description:

# Endpoint in 4.0
<factoryEndpoint
  xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
  <wsa:Address>
    https://grid-w.ncsa.teragrid.org:8444/wsrf/services/ManagedJobFactoryService
  </wsa:Address>
  <wsa:ReferenceProperties>
    <gram:ResourceID>Fork</gram:ResourceID>
  </wsa:ReferenceProperties>
</factoryEndpoint>

# Endpoint in 4.2
<factoryEndpoint
  xmlns:gram="http://www.globus.org/namespaces/2008/03/gram/job"
  xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <wsa:Address>
    https://grid-w.ncsa.teragrid.org:8444/wsrf/services/ManagedJobFactoryService
  </wsa:Address>
  <wsa:ReferenceParameters>
    <gram:ResourceID>Fork</gram:ResourceID>
  </wsa:ReferenceParameters>
</factoryEndpoint>

GRAM4 in 4.2 defines a default local resource manager which is used for job execution if the user did not explicitly specify one. A user however still can specify a local resource manager (LRM), e.g. if it's required that a job runs in a certain LRM. Check

globusrun-ws in 4.0 sets a default lifetime of 24h on a job if a user does not explicitly set it. In 4.2 a job will run to completion in any event if no lifetime is specified, i.e. it will not be terminated after 24h.

However, there are server-side settings define limits on an explicitly requested lifetime, and that determine what will happen to a completed job if no lifetime had been set. Check section Job Lifetime in the Execution key concepts and section Job Lifetime in the User's Guide for more information.

Due to the WSRF, WSN and WS-Adressing specification upgrade namespaces of many components have changed. Check section Specification upgrade related changes and the Java WS Core Migration guide for details.

GRAM4 does not extend from the ImmediateResourceTermination port type anymore, i.e. the Destroy() operation is no longer available to synchronously destroy job resources. Instead GRAM4 offers an asynchronous Terminate() method that lets clients terminate jobs and destroy a job resource. Check the TerminateManagedJobPortType PortType in the section 'WSDL and Schema Definition' of the Developer's guide for details and section Job termination for explanations of the new termination interface.

The Java API GramJob in 4.0 sets a default lifetime of 24h on a job if a developer does not explicitly set it. In 4.2 it will not be set and a job will run to completion in any event if no lifetime is specified, i.e. it will not be terminated after 24h.

However, there are server-side settings define limits on an explicitly requested lifetime, and that determine what will happen to a completed job if no lifetime had been set. Check section Job Lifetime in the Execution key concepts and section Job Lifetime in the User's Guide for more information.

In GRAM4 in the 4.0 series a client had to destroy subscription resources before destroying a job if it subscribed for notifications in order to cleanup state on the server-side. In GRAM4 in 4.2 all subscription resources of a job resource are destroyed on the server-side automatically if a job resource is destroyed. There's no need to keep track of subscription resources anymore.

In GRAM4 an administrator can configure a default local resource manager (LRM) being used for job submission if the client did not specify any in a job submission request. To submit a job to the default local resource manager just don't put a ReferenceParameters element in the EndpointReference used to contact GRAM4's job factory service. By querying resource properties of GRAM4's factory service a client can find out which local resource manager is the default, or which LRM's are available on the server-side.

In GRAM4 in GT 4.0 the client-side generated submission being set in CreateManagedJobInputType.JobID had been used as server-side job id for multi-jobs. In GRAM4 in 4.2 a UUID is created on the server-side to manage the job and the client-side generated ID will only be stored to enable reliable job submission. A client cannot use the self-generated id for any job operation besides a second submission call for multi-jobs anymore. See section Client-Side Generated Submission ID for more information about this.

In GRAM2, jobs are submitted to a job manager process started by a Gatekeeper process. The Gatekeeper process is typically started out by an inetd server, which forks a new gatekeeper per job. In GRAM4, jobs are started by the ManagedExecutionJobService, which is a Java service implementation running within the globus service container.

The gatekeeper searches the $GLOBUS_LOCATION/etc/grid-services directory to determine which services it will start. Typically there is one job manager service entry file in that directory per scheduler type.

In GRAM2, all file system and scheduler interactions occur within a perl module called by the globus-job-manager-script.pl program. Scheduler-specific perl modules implement a number of methods which are used by the job manager:

Only a small set of these script methods are used in the GRAM4 implementation. The subset used is:

Some of the functionality has been moved into other services for reliability or performance reasons. Other functions have been removed altogether.

In GRAM2, each job submitted would cause the following processes to be created:

In GRAM4, each job causes the following processes to be created

Additionally, there will be a per-scheduler instance of the SEG program, monitoring a log file for job state changes.

Typical interactions with the GRAM2 service were done with either the globusrun or command or the globus-job suite of scripts (globus-job-submit, globus-job-run, globus-job-get-output, globus-job-status, globus-job-clean). The main difference between these sets of commands is that globusrun required a job description in RSL format, and the globus-job-submit and globus-job-run scripts would construct that based on command line options.

In GRAM4, the globusrun-ws command implements the functionality of globusrun using the XML Job Description language in place of the RSL format job description of GRAM2. It also allows specifying parts of the Job Description with simple command line arguments (for executable and arguments), similar to what one would do with globus-job-run. Like globusrun, the globusrun-ws program supports both the interactive and batch submission of GRAM jobs.

Note 1: In GRAM2, streaming is done using https connections from the job manager to a GASS server embedded in the globusrun program. In GRAM4, streaming is implemented by accessing a gridftp server configured to run along with the service container.

globusrun-ws has additional options to deal with file streaming, monitoring an existing job, authentication and authorization, http timeouts, default termination time, encryption, etc.