Page History

...

When submitting jobs to remote sites the Pipeline II server still runs a single instance at SLAC. Batch jobs are submitted (at SLAC or elsewhere) using a simple batch submission daemon which is designed to hide the details of the batch submission process from the Pipeline II server. When jobs start they send an initial e-mail back to the pipeline server, and when they complete they send an a second e-mail stating that they have finished (successfully or not). A data catalog is maintained at SLAC which can contain information on data available at SLAC or elsewhere. Batch jobs to do not communicate directly with the database or with the pipeline II server.

...

The Job Submission daemon is a separate Java project in GLAST CVS, with some documentation available here.
Strictly speaking the pipeline server can work with anything that extends the JobControlClient class, which allows jobs to be submitted, queried for their status, and canceled. In practice only a couple of classes in the implementation of the job control client depend on LSF, so we expect remote sites to run a modified version of the standard JobControlClient. The classes which depend on LSF are:

...

The standard implementation of JobControlClient uses Java Remote Method Invocation (RMI) to communicate with the server, so it should be quite possible for the daemon to run on a remote site. There may be some issues with firewall's firewalls at remote sites, but the server can be configured to run on any port, and only requires incoming connections to be allowed from a small set of hosts at SLAC where we run the pipeline II server.

...

Once a JobControlService is available which allows submission to remote site we will need to set up the pipeline II server to work with it. While the server was designed to allow this, it has not yet been tried, and going from one site to more than one sight site will certainly require some work to allow additional configuration of the server.

Installing GLAST software at remote site

...